Utilisation de feuilles de calcul agiles pour l'estimation de la découverte

Cet article comprend une feuille de calcul préformatée pour vous aider à développer des estimations de découverte Agile. Il comprend également des informations pour vous aider à suivre l'exemple présenté. Vous pouvez faire une copie modifiable (Fichier> Faire une copie ou Fichier> Télécharger) à partir du modèle ici.

Les clients me demandent souvent de fournir des estimations Agile avant que j'aie une équipe en place ou que je connaisse les exigences du MVP. À ce stade précoce, je n'ai pas accès aux mesures traditionnelles telles que la vélocité, le nombre de sprints ou le coût de l'équipe pour calculer ces estimations. Mais les clients veulent des réponses. Peuvent-ils lancer un produit hypothétique en deux mois ou six ? Sera-t-il faisable pour leur budget (généralement faible) ?

Entrez dans la feuille de calcul Agile.

Les feuilles de calcul sont un choix approprié, mais souvent négligé, pour un état d'esprit Agile. Ce sont des outils low-tech et high-touch qui encouragent la collaboration. Cela dit, votre client ne se soucie probablement pas de savoir si vos outils sont « approuvés Agile » tant que le coût et la qualité du produit répondent à ses exigences. La véritable valeur des feuilles de calcul réside dans leur accessibilité aux chefs de projet et aux parties prenantes de tous niveaux d'expérience.

De nombreux outils de gestion de projet spécialisés ont des courbes d'apprentissage trop abruptes pour les utilisateurs inexpérimentés sur des projets rapides. Ainsi, plus il est facile pour les clients, les propriétaires de produits et les développeurs de mettre à jour les exigences et les coûts de main-d'œuvre, plus tôt vous arriverez à une estimation réaliste. Avec une feuille de calcul préformatée, les chefs de projet peuvent ajuster les valeurs et les paramètres pour démontrer les effets de chaque ressource fluctuante ou de chaque changement de calendrier.

Les feuilles de calcul sont également un excellent moyen de partager des connaissances avec vos collègues. La feuille de calcul que j'utilise provient d'un collègue de Toptal, et j'en ai depuis fait une copie et l'ai modifiée pour répondre à mes besoins. Je vous encourage à le faire également.

Dans cet article, je montre comment fournir des estimations de découverte réussies qui permettent aux clients et aux parties prenantes de s'aligner sur les objectifs du projet et de poursuivre le développement. Voici comment remplir les blancs et fournir une estimation préliminaire sur laquelle vous pouvez vous appuyer.

Abordez d'abord la vision et la feuille de route du produit

Supposons que votre client souhaite développer un site de rencontres avec un budget fixe, mais que les détails du produit sont flous. Sans connaître le coût et la vitesse de l'équipe, la vision du produit est le meilleur point de départ car elle nécessite que les parties prenantes s'accordent sur un objectif de conception et favorise la transparence au sein de l'équipe.

J'aime le format de vision du produit Scrum.org pour son style narratif intuitif. Voici à quoi ça ressemble :

Une fois la vision du produit définie, vous pouvez ajouter la feuille de route du produit dans un nouvel onglet de feuille de calcul pour donner au client une idée du calendrier du projet à long terme. La feuille de route doit répertorier les objectifs, les fonctionnalités clés et les délais pour chaque version de la feuille de route du produit.

Les versions de feuille de route sont des éditions planifiées, destinées aux consommateurs ou aux clients d'un produit qui guident sa trajectoire sur le marché. La première version de la feuille de route est le produit que vous pouvez lancer sur le marché. Les versions ultérieures de la feuille de route représentent les versions du marché avec de nouvelles fonctionnalités convaincantes qui s'alignent sur la vision du produit.

Pour utiliser Microsoft comme exemple : Windows 8 était probablement une version de feuille de route. Windows 10 était une autre version de la feuille de route qui comportait de nombreuses fonctionnalités nouvelles et souhaitables.

Une fois la vision et la feuille de route du produit terminées, il est temps de demander au client de s'engager envers un MVP.

Négocier les fonctionnalités MVP avec le graphique à triple contrainte

C'est le moment de façonner les attentes de votre client en matière de temps et de dépenses à l'aide du tableau des triples contraintes :

Dans une approche en cascade, les caractéristiques fixes dictent le temps et le coût, et le développement se déroule selon un plan de projet détaillé. À l'inverse, les coûts fixes et le calendrier d'Agile déterminent les fonctionnalités du produit, et ces fonctionnalités sont constamment repriorisées en fonction de la vision plus flexible du projet.

Le graphique Triple contrainte montre au client que l'inclusion de toutes les fonctionnalités souhaitées dans la première version augmentera le temps de développement et les coûts de ballon. Au lieu de cela, travaillez avec le client pour sélectionner uniquement les fonctionnalités « indispensables » pour un MVP et tablez toutes les fonctionnalités restantes pour les futures versions.

Les feuilles de calcul facilitent le regroupement et la réaffectation des fonctionnalités à différentes versions, versions et priorités en fonction des besoins changeants du client, et elles affichent instantanément les coûts de ces modifications.

Pendant que vous identifiez les fonctionnalités MVP, demandez à vos experts en la matière (PME) de vous aider à répertorier les étapes du projet en fonction de projets similaires sur lesquels ils ont travaillé. Vous utiliserez ces étapes pour créer des epics plus tard. Une fois que vous avez ces entrées prêtes, vous pouvez commencer à établir une estimation.

Commencez par la taille du t-shirt

Pour commencer le premier backlog, demandez au Product Owner une description détaillée des fonctionnalités du produit, puis attribuez une taille de T-shirt à chaque fonctionnalité en fonction de son niveau de difficulté.

Le dimensionnement des t-shirts montrera la complexité et la durée relatives de chaque tâche de développement avant que vous n'ayez des valeurs absolues. Au fur et à mesure que nous avancerons dans la planification du projet, nous convertirons ces tailles relatives en points d'histoire et en heures de travail.

Par exemple, si votre client souhaite que vous développiez une série de pop-ups sur le site de rencontre, cela prendrait du temps mais serait simple. Vous pourriez qualifier cette complexité de tâche de « petite », mais l'effort serait « moyen ». Vous pouvez l'abréger en "SM". D'autre part, développer une connexion back-end pour une nouvelle API serait une tâche plus complexe en raison de toute la documentation et des tests requis. La compétence et l'attention nécessaires pour cela pourraient en faire un "Grand" à la fois en termes d'effort et de niveau de compétence : "LL".

Une fois que vous avez terminé le dimensionnement du t-shirt, vous aurez une idée de la charge de travail relative et des compétences requises pour chaque futur membre de l'équipe. Un expert technique de l'équipe de développement peut ensuite vous aider à corréler la taille de votre t-shirt à des plages d'heures et de points d'histoire.

Définissez vos paramètres

Vous êtes maintenant prêt à utiliser votre feuille de calcul et à calculer votre estimation. Commencez par créer un onglet Paramètres. Cela servira de clé pour vos calculs, et les valeurs que vous entrez ici alimenteront les formules utilisées dans vos onglets Backlog/User Stories et Estimate Summary by Release.

Voici tout ce dont vous aurez besoin dans votre onglet Paramètres :

Devise. C'est ici que vous entrez les conversions de devises. Par exemple, si le budget du client est en réaux brésiliens, vous pouvez entrer le taux de conversion actuel pour les dollars ou les euros.

Date de début. La date de début de développement prévue sera utilisée pour créer un calendrier de projet. Dans chaque exemple, notre date de début est le 25 octobre.

Budget initial. Le budget fournit des contraintes qui indiquent si toutes les fonctionnalités MVP s'y intégreront ou non.

Taille du t-shirt. Entrez vos tailles de t-shirt sous forme de tableau et attribuez des points d'histoire et une plage d'heures à chaque combinaison de tailles. Dans cet exemple, nous utilisons une à deux heures pour un SS et 33 à 48 heures pour un LL.

Gardez à l'esprit que la durée de votre sprint limitera les heures de votre taille de t-shirt maximale. Si le sprint ne dure qu'une semaine, la plus grande taille ne peut pas dépasser 40 heures. C'est pourquoi la consultation d'une PME est si importante lors de l'attribution des tailles de T-shirt aux tâches .

Tarifs à l'heure. Utilisez ce tableau pour documenter les taux de rémunération pour chaque rôle. Si vos développeurs back-end ont des taux différents, utilisez la moyenne des deux.

Aérien. Attribuez un pourcentage de l'effort total du projet aux tâches administratives telles que les réunions d'état, les sessions de rétroaction et les révisions de projet. Dix pour cent (ou quatre heures de la semaine de travail de chaque participant) est un bon point de départ, mais les frais généraux peuvent être plus élevés pour des projets plus complexes.

Contingence. Cela indique l'écart potentiel dans votre estimation. Commencer avec une contingence de 0 % vous montrera le budget et le calendrier les plus favorables (c'est-à-dire peu probables) compte tenu des valeurs que vous avez entrées dans la feuille de calcul. Plus loin dans notre exemple, nous augmenterons la contingence à un écart d'un ordre de grandeur approximatif (ROM) de 50 % pour montrer le potentiel haut de gamme des coûts et de la durée du projet. La contingence diminuera à mesure que vous obtiendrez des chiffres plus précis.

Dimensionnez chaque version avec des épopées

Nous commençons par un dimensionnement approximatif du produit complet pour nous assurer de ne pas faire perdre de temps ou d'argent au client. En fonction de la proximité du dimensionnement par rapport au budget et au délai proposés, le client peut décider d'abandonner le projet ou d'investir dans des estimations plus détaillées. Comme nous n'avons pas beaucoup de détails à ce stade, nous entrons les principales fonctionnalités sous forme d'épopées dans l'onglet Backlog/User Stories. Ensuite, pour chaque épopée, nous saisissons le nombre d'heures que les PME et les responsables du développement ont suggéré pour chaque pile de développement en fonction du tableau des tailles de T-shirt dans l'onglet Paramètres.

Tout d'abord, sélectionnez la colonne « EPIC ? » et assurez-vous que seul "Epic" est sélectionné.

Ensuite, écrivez la description épique et entrez le nombre d'heures pour chaque colonne de la pile de développement. Par exemple, l'épopée "Connexion et connexion sécurisées" prendra environ huit heures de développement d'interface utilisateur, 40 pour le back-end, etc.

Notez que dans la plupart des cas, les cellules de la colonne "Point" affichent "34*". Si vous revenez dans l'onglet Paramètres, vous verrez que 34 points correspondent à une plage horaire comprise entre 33 et 48 heures. Ce nombre d'heures est trop important si la durée de notre sprint n'est que d'une semaine.

Une fois que nous aurons plus de détails, ces heures devront être réduites ou les épopées devront être divisées en histoires plus gérables. Pour des raisons de temps, cependant, nous allons ignorer la colonne Points et continuer avec l'estimation approximative.

Accédez maintenant à l'onglet Résumé de l'estimation par version. En haut de la feuille de calcul, vous verrez les valeurs "Overhead" et "Contingency" telles que définies dans l'onglet Paramètres. Il existe également un bouton que vous pouvez sélectionner pour afficher les estimations par epics ou user stories.

Comme nous n'avons pas encore d'histoires d'utilisateurs à afficher, cochez le bouton "Mode épique".

Vous pouvez maintenant voir le coût approximatif et les délais du MVP ainsi que les fonctionnalités et mises à jour moins urgentes dans les futures versions (R3 et R4). Dans cet exemple, la deuxième version (R2) est vide car le client a demandé que toutes les epics MVP soient lancées dans la première version.

Vous pouvez maintenant voir le coût global le plus optimiste : 28 810 $. Ce chiffre est la somme du coût de chaque version du MVP à R4.

Nous avons également une estimation du délai le plus court pour la livraison du produit, qui correspond à la dernière date d'achèvement dans la pile de développement R4. Les chefs de projet appellent ces piles de développement plus lentes des "chemins critiques" car elles dictent la vitesse de l'ensemble de la version.

Dans ce cas, le chemin critique est le développement frontal, avec une date d'achèvement au 31 janvier.

Il est maintenant temps d'ajuster les paramètres pour simuler le budget le plus défavorable et le délai le plus long.

Ajustez la contingence à 50 %

Nous savons encore relativement peu de choses sur les exigences d'effort et d'expertise pour le produit, nous allons donc ajouter une contingence ROM de 50 % dans l'onglet Paramètres. La contingence diminuera à mesure que nous apprendrons plus de détails sur le projet.

Encore une fois, voici l'estimation totale du projet à 0 % de contingence.

Et le voici à 50% de contingence.

Cela signifie que l'estimation de la ROM pour l'ensemble du projet se situe entre 28 810 $ et 41 860 $. Dans le meilleur et le pire des cas, le budget de 20 000 $ du client ne suffira pas à inclure toutes les fonctionnalités de sa liste de souhaits.

La date d'achèvement complète du projet à 50 % de contingence tombe désormais le 14 mars, six semaines plus tard que la date d'achèvement de 0 % de contingence.

En attendant, le MVP sera prêt le 10 janvier.

Au lieu d'abandonner le projet, le client demande une estimation plus détaillée pour voir s'il pourrait se rapprocher de son budget cible dans un délai plus court.

Redéfinir les priorités pour respecter les délais

Supposons que le client fixe une date cible du 25 décembre pour le MVP, deux mois après le coup d'envoi du 25 octobre.

Pour avancer la date d'achèvement actuelle du 10 janvier MVP, le client a accepté de retarder deux épopées MVP jusqu'à la prochaine version (R2).

Le tableur calcule l'effet en cascade de cet ajustement. Dans ce cas, la chronologie du MVP se raccourcit au 27 décembre. Le développement front-end et back-end sont les chemins critiques de cette simulation car ils prendront le plus de temps à se terminer.

Sur la base de ces informations, vous pouvez décider d'ajouter deux autres développeurs pour aligner les dates d'achèvement front-end et back-end avec les autres piles de développement. Pour ce faire, augmentez les heures de 40 à 80 dans la ligne MVP "Heures par semaine".

Les piles de développement front-end et back-end se terminent désormais en novembre, et l'assurance qualité devient le nouveau chemin critique (avec une date d'achèvement fixée au 20 décembre). Notez que le coût ne change pas. C'est parce que le nombre total d'heures de travail dans chaque pile reste le même. Au lieu d'un développeur travaillant pendant deux semaines (80 heures), deux développeurs travaillent pendant une semaine (80 heures).

La feuille de calcul tient également compte des différences entre le travail à temps plein et à temps partiel. Supposons que le développeur de l'interface utilisateur travaille à temps partiel. Nous pouvons modifier l'interface utilisateur "Design Hours per week" à 20 pour simuler le retard de livraison.

Sur un horaire à temps plein, UX/UI sera terminé le 29 novembre.

Sur un horaire à temps partiel, UX/UI sera terminé le 27 décembre.

Encore une fois, le coût ne change pas, mais UX/UI devient le nouveau chemin critique, prolongeant le calendrier du MVP jusqu'au 27 décembre.

Vous pouvez continuer cette approche par essais et erreurs jusqu'à ce que vous arriviez à un chemin critique acceptable compte tenu de vos ressources et du délai du client. Une fois qu'un délai approprié est en place, il est temps de commencer à peaufiner votre estimation.

Affinez votre estimation avec les témoignages d'utilisateurs

Étant donné que l'estimation de 50 % des imprévus ne correspondait pas au budget du client, il vaut la peine d'affiner vos variables afin de pouvoir réduire l'imprévu et d'obtenir une estimation plus réaliste.

Pour ce faire, travaillez avec vos développeurs et PME pour décomposer vos epics en user stories détaillées. Les histoires sont mieux définies que les épopées, nous pouvons donc les dimensionner plus précisément.

Ensuite, ajustez les valeurs dans votre onglet Paramètres en fonction de toute nouvelle information. Par exemple, votre PME et votre équipe de développement peuvent disposer d'un ensemble de taux plus précis pour chaque rôle et peuvent également vouloir ajuster les tailles de t-shirts et les attributions de points. Avec ces nouveaux paramètres en place, vous pouvez avoir une plus grande confiance dans vos calculs et réduire la contingence à 25 %.

Voyons comment nous avons divisé les epics en user stories plus petites et plus détaillées :

Contrairement à l'estimation épique qui nécessitait de saisir manuellement les heures estimées pour chaque pile, l'estimation de l'histoire utilise la taille du t-shirt comme raccourci. C'est là que les tailles de t-shirts que vous avez saisies dans l'onglet Paramètres sont utiles.

Sous "T-shirt Sizing" dans l'onglet Backlog/User Stories, entrez la combinaison de taille que vos développeurs et PME ont attribuée à leurs piles pour chaque histoire. À partir de là, la formule de la feuille de calcul remplira automatiquement les heures correspondantes à partir de l'onglet Paramètres. N'oubliez pas que la plus grande taille, LL, doit rester inférieure à 34 points pour s'assurer qu'elle peut être complétée dans la durée de sprint convenue. Toutes les histoires qui obtiennent encore 34 points ou plus devront être subdivisées.

Une fois que vous vous êtes assuré que moins de 34 points sont attribués à toutes les histoires, décochez le bouton "Epic Mode" dans l'onglet Estimate Summary by Release afin de n'afficher que "Story".

Vous verrez maintenant un nouvel ensemble de nombres :

Après avoir détaillé toutes les tâches et s'en tenir aux fonctionnalités MVP uniquement, le calendrier et le coût correspondent désormais aux exigences du client. Étant donné que le solde respecte largement son budget, le client décide de poursuivre avec le MVP et de le tester avant de s'engager dans des versions supplémentaires.

Faites en vôtre

Les feuilles de calcul sont simples à utiliser et, avec une connaissance de base des formules (pas de macros nécessaires), vous pouvez les adapter à presque tous les besoins. Si vos connaissances sur Excel sont rouillées, des cours en ligne sur Udemy et edX vous aideront à perfectionner ces compétences.

Cet article couvrait l'estimation de la découverte, mais vous pouvez utiliser la même feuille de calcul pour produire des graphiques burnup/burndown, ajuster les délais et calculer les estimations en fonction de la vélocité et des sprints pour les étapes ultérieures. J'utilise mes feuilles de calcul personnalisées pour compléter des applications telles que Jira, Asana et Trello, et je maintiens qu'elles constituent un outil puissant dans mon kit de gestion de projet. J'espère qu'ils s'avéreront tout aussi utiles et polyvalents pour vous.

Préférez-vous les feuilles de calcul personnalisées aux outils de gestion de projet prêts à l'emploi ? Dites-nous pourquoi ou pourquoi pas dans les commentaires.