Comment estimer les Story Points de votre projet ?
Dans le cadre d'un projet Agile, l'équipe anticipe les tâches des sprints à venir en élaborant des récits utilisateurs. Chaque récit décrit une action unique, englobée dans une fonctionnalité, avec une explication et des critères de réussite.
Les sprints durent généralement entre deux et quatre semaines. Durant cette période, l'équipe doit évaluer la quantité de travail qu'elle peut accomplir dans un sprint, afin de respecter les délais impartis.
Dans un projet non-Agile, on évaluerait généralement le travail en jours-homme, c'est-à-dire le nombre d'employés à plein temps nécessaires pour achever une tâche. Cette approche met l'accent sur la durée et le nombre de personnes.
En Agile, la méthode est différente. On ne calcule plus en jours ou en nombre de personnes pour déterminer l'effort. On proscrit même l'estimation en jours-homme. À la place, l'équipe utilise une valeur consensuelle pour chaque récit, représentant son estimation globale.
La nature précise de cette valeur importe peu. Les points d'histoire, basés sur la suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, etc.), sont couramment employés. Chaque nombre suivant est la somme des deux précédents, ce qui permet de mieux distinguer la complexité des récits, car chaque valeur supérieure est significativement plus grande.
Toutefois, il n'est pas obligatoire d'utiliser les points d'histoire. On peut aussi se servir de tailles de vêtements (XXS, XS, S, M, L, XL, XXL) ou, pour plus d'originalité, des noms d'animaux de zoo.
L'essentiel est que toute l'équipe se mette d'accord sur le nombre (ou l'animal) qui représente le mieux la complexité d'un récit donné. Il ne s'agit en aucun cas d'une représentation temporelle. L'équipe doit achever chaque récit inclus dans le sprint, dans le délai imparti, qui est une constante dès le départ.
Éléments clés de l'estimation en points d'histoire
L'estimation en points d'histoire ne se limite pas à la complexité ou à la difficulté d'un récit. Plusieurs facteurs doivent être pris en compte et reflétés dans la valeur finale.
Cette valeur est le résultat d'une combinaison de tous ces éléments en un seul chiffre. Voici les facteurs principaux à considérer.
#1. Complexité technique
Pour une équipe de développement, la complexité technique est généralement le premier aspect évalué lors de l'estimation d'un récit.
Il s'agit d'une approche pertinente. L'équipe technique doit savoir évaluer cet aspect d'un récit. Elle peut considérer plusieurs critères :
- Comment ce récit se compare-t-il aux précédents en termes de complexité technique ?
- Combien de fichiers de code l'équipe devra-t-elle créer ou modifier pour achever le récit ?
- Combien de changements de code supplémentaires ce récit entraînera-t-il dans les processus environnants ?
- Quelle sera la complexité de l'algorithme ou de la logique de processus à implémenter ?
#2. Dépendances et risques externes
On pourrait être surpris, mais la réussite des récits au sein d'un sprint dépend souvent des contributions d'autres équipes ou de personnes extérieures.
Les récits que l'équipe peut réaliser seule sont plus faciles à évaluer. Les choses se compliquent lorsque l'équipe a besoin d'une aide externe. Cette aide n'étant pas une priorité pour les intervenants externes, l'équipe doit tenir compte de ce facteur dans son estimation.
L'impact de ce facteur sur l'estimation globale dépendra principalement de l'expérience passée de l'équipe et de son "niveau d'externalité". Avec l'habitude, l'équipe développera une intuition pour évaluer la complexité induite par ces dépendances.
#3. Facteur de réutilisabilité
Le niveau de réutilisation de contenu existant est un autre élément à considérer. Si des éléments sont déjà disponibles, il n'est pas nécessaire de tout reconstruire. L'équipe peut réutiliser des solutions existantes, ce qui accélère le processus.
Cette réutilisabilité peut réduire l'estimation globale, même si un récit, en l'absence de cette option, serait plus complexe.
#4. Connaissance de sa propre équipe
Un facteur crucial, que l'estimation en jours-homme ne prend pas en compte, est la connaissance de l'ancienneté et des compétences de l'équipe.
Au fil des sprints, les membres de l'équipe apprennent à se connaître, à identifier les forces de chacun. Cette connaissance mutuelle permet d'affiner l'estimation.
Si un récit fait appel à une compétence technique spécifique et que cette compétence est bien représentée au sein de l'équipe, sa réalisation sera moins compliquée. À l'inverse, un manque de compétences spécifiques dans l'équipe nécessitera plus de temps, ce qui doit être reflété dans l'estimation.
Le processus d'estimation
L'estimation d'un récit doit être un travail d'équipe. Aucune opinion ne doit prévaloir. Le but est d'ouvrir la discussion jusqu'à ce que tous les membres s'accordent sur une seule valeur.
L'estimation peut avoir lieu pendant la réunion de préparation du sprint, où les récits sont discutés et clarifiés, ou lors d'une session dédiée.
Exemple de processus d'estimation
- Choisir un outil d'estimation, tel que Planning Poker, un tableau Miro, ou un outil similaire.
- Présenter un récit. L'équipe discute et pose des questions pour s'assurer que tout le monde le comprend et est prêt à l'évaluer.
- Commencer l'estimation. Chaque membre de l'équipe choisit un nombre de la suite de Fibonacci.
- Comparer les estimations. Une discussion est lancée, en général, les avis oscillent entre deux ou trois valeurs. Les personnes ayant choisi l'estimation la plus basse expliquent leur point de vue. Ensuite, les personnes avec l'estimation la plus haute font de même. Le but est de rassembler tous les arguments, les faits, pour une compréhension commune du récit.
- Après la discussion, l'équipe vote à nouveau. Les avis convergent généralement vers une ou deux valeurs. La discussion reprend. Selon le contexte, l'équipe s'accorde sur la valeur finale ou effectue un autre tour d'estimation.
- L'estimation n'est terminée que lorsque tous les membres de l'équipe sont d'accord avec la valeur finale. Il s'agit d'un accord collectif, car potentiellement, chaque récit peut être attribué à n'importe qui dans l'équipe. Il est donc essentiel que chacun soit d'accord sur la complexité du récit.
Engagement du plan de sprint
L'équipe dispose maintenant d'un backlog avec des récits estimés. Idéalement, les récits ont été classés par ordre de priorité, ce qui permet de savoir quels seront les prochains récits à traiter durant le prochain sprint.
Lors de la planification, l'équipe choisit les récits à inclure dans le prochain sprint, en se basant sur :
✅ Les récits ayant la priorité la plus élevée.
✅ L'expérience de l'équipe concernant le nombre de points d'histoire qu'elle peut réaliser en un sprint. Cette connaissance s'affine avec le temps et l'expérience.
✅ L'équilibre des compétences au sein de l'équipe. Par exemple, une équipe avec peu de développeurs front-end ne doit pas choisir uniquement des récits de développement front-end. Cela surchargerait les développeurs concernés. La répartition des compétences est donc essentielle à l'efficacité du sprint.
Facteur de vélocité
La vélocité de l'équipe, pour le sprint à venir, est un facteur primordial. Cette valeur n'est pas liée au total des points d'histoire, mais elle indique la capacité de travail de l'équipe pour le sprint.
Pour planifier avec précision le contenu d'un sprint, on utilise deux indicateurs :
- Vélocité de l'équipe (en jours) : Un membre de l'équipe disponible une journée équivaut à 1 point de vélocité. Une équipe de 10 personnes disponibles à plein temps durant un sprint de 2 semaines aura une capacité de 100.
- Quantité habituelle de points d'histoire réalisée en un sprint. Ce nombre est lié à l'expérience passée et à la vélocité de l'équipe.
Trouver le juste équilibre demande du temps et de la pratique.
Avantages et erreurs courantes
De nombreuses équipes complexifient le processus lors de leur transition vers l'agilité. Il est crucial de comprendre ce changement de méthode avant de pouvoir travailler efficacement.
Cette étape initiale est souvent la plus difficile, elle peut même prendre des années, surtout dans des contextes d'entreprise très conservateurs.
Voici les avantages une fois que l'équipe a "compris" :
- Il n'est plus nécessaire de calculer le nombre de personnes ou de jours pour estimer la durée d'une tâche.
- L'équipe apprend à créer des récits adaptés à la durée d'un sprint. Si un récit est trop complexe, il est divisé en plusieurs récits.
- L'équipe dispose d'estimations fiables pour chaque tâche. Une fois qu'un sprint est planifié, on connaît les délais exacts.
- La fiabilité et la prévisibilité de l'équipe augmentent.
- Tous les membres de l'équipe sont "sur la même longueur d'onde". Ils comprennent les mêmes choses lorsqu'ils évaluent un récit. Avec l'expérience, ils n'ont même plus besoin d'estimer explicitement. Ils ont une idée commune de la complexité du récit et peuvent s'engager sans estimation formelle.
Voici ce qui peut se passer si l'équipe n'a pas compris le processus :
- L'équipe utilise toujours des estimations en jours-homme. Elle convertit les points d'histoire en jours, directement ou indirectement.
- La direction compare les équipes en fonction des points d'histoire réalisés à chaque sprint. C'est une erreur, car chaque équipe évalue les points d'histoire différemment. Il n'est pas nécessaire de synchroniser les équipes.
- Par exemple, pour une équipe, un cercle peut être un projet simple, tandis que pour une autre, cela peut être une maison avec un toit plat, quatre fenêtres et deux portes.
- Les équipes ont tendance à limiter leurs estimations à quelques valeurs. L'échelle de Fibonacci n'a pas de limite. Il est inutile de se limiter à des estimations de 3, 5 ou 8. Si l'équipe crée des récits avec cette idée en tête, ce n'est pas un problème, mais il n'y a aucune obligation.
- Les estimations sont influencées par les membres les plus anciens de l'équipe. Chaque membre a le droit d'exprimer son opinion et d'être entendu.
Derniers mots
La transition vers une estimation Agile est un défi qui nécessite une adaptation, tant pour les équipes que pour la direction. Les deux parties doivent comprendre le processus. Sinon, la transition sera difficile, pleine d'attentes contradictoires.
Une fois la transformation réussie, des améliorations significatives apparaissent. Les équipes planifient et estiment leur travail plus efficacement, et la direction dispose de calendriers et de feuilles de route plus fiables.
N'oubliez pas de vérifier les processus malsains qui pourraient nuire à votre sprint.