Estimation de la charge de travail avec les Story Points

1. Au-delà des heures : introduction aux Story Points

En tant que développeur, vous savez que deux tâches qui semblent prendre le même temps peuvent avoir des niveaux de difficulté radicalement différents. Une tâche peut être longue mais simple et répétitive, tandis qu'une autre peut être courte mais impliquer une recherche complexe et un risque technique élevé.

Les estimations en temps (heures/jours) sont fragiles car elles dépendent de qui fait le travail, des interruptions, et de notre optimisme naturel. Les méthodes agiles proposent une autre approche : les Story Points.

Un Story Point n'est pas une unité de temps. C'est une unité de mesure relative qui évalue la "taille" d'une user story selon trois axes :

1. L'effort : la quantité de travail à fournir.
2. La complexité : la difficulté technique ou intellectuelle.
3. L'incertitude et le risque : les inconnues, les dépendances, le risque de découvrir des problèmes en cours de route.

L'idée clé est la relativité. On ne dit pas "cette tâche prendra 2 jours", mais "cette tâche est environ deux fois plus grosse que cette autre tâche de référence".

Pour vous aider à visualiser ce que ces points peuvent représenter en pratique, voici un "aide-mémoire" qui associe des valeurs de points à des scénarios de travail.

2. Le Planning Poker : Estimer en équipe

Maintenant que nous savons ce que sont les story points, comment une équipe se met-elle d'accord sur une estimation ? La technique la plus répandue et la plus efficace est le Planning Poker.

C'est une activité collaborative, presque un jeu, où l'équipe de développement estime collectivement les user stories. L'objectif n'est pas d'atteindre une précision absolue, mais de créer une compréhension partagée et de révéler les hypothèses cachées de chacun.

La vidéo suivante explique de manière très vivante et détaillée le déroulement d'une session de Planning Poker.

Pour résumer, le processus du Planning Poker se déroule comme suit :

1. Présentation : Le Product Owner présente une user story.
2. Clarification : L'équipe de développement pose des questions pour clarifier les aspects fonctionnels. On évite de parler de la solution technique à ce stade.
3. Estimation individuelle : Chaque membre de l'équipe choisit secrètement une carte correspondant à son estimation (en utilisant une échelle comme la suite de Fibonacci : 1, 2, 3, 5, 8, 13...).
4. Vote simultané : Tout le monde révèle sa carte en même temps. Cela évite le "biais d'ancrage", où la première personne qui parle influence tout le groupe.
5. Discussion :
   • Si tout le monde a voté la même chose (ou des valeurs très proches), l'estimation est adoptée et on passe à la story suivante.
   • Si les votes sont très différents, on demande à ceux qui ont voté le plus bas et le plus haut d'expliquer leur raisonnement. Cette discussion est la partie la plus précieuse du processus, car elle révèle des compréhensions différentes de la tâche.
6. Re-vote : Après une brève discussion (time-boxée à 1 ou 2 minutes), l'équipe vote à nouveau. On répète le cycle jusqu'à ce qu'un consensus soit atteint. Si une story est estimée très haut (ex: 13 ou plus), c'est un signal qu'elle est trop grosse ou mal comprise et qu'elle doit être découpée.

3. De l'estimation à la prévision : la Vélocité

Estimer chaque story, c'est bien, mais comment cela nous aide-t-il à estimer la charge de travail globale d'un projet ? La réponse est la vélocité.

La vélocité est simplement la quantité de story points qu'une équipe de développement arrive à terminer durant un sprint.

Après quelques sprints, vous pouvez calculer la vélocité moyenne de l'équipe. Par exemple, si l'équipe a terminé 25, 30 et 28 points lors des trois derniers sprints, sa vélocité moyenne est d'environ 28 points.

Cette métrique devient un outil de prévision puissant :

• Pour le Sprint Planning : L'équipe sait qu'elle peut raisonnablement s'engager sur environ 28 points pour le prochain sprint.
• Pour la planification à long terme : Si le reste du backlog produit est estimé à 140 points, on peut prévoir qu'il faudra environ 5 sprints pour le terminer (140 / 28 = 5).

Voici à quoi ressemble le résultat dans un outil de gestion de projet. On voit bien la somme des points estimés pour chaque sprint, ce qui représente la charge de travail engagée.

4. Mise en pratique : Estimons le projet "Chez Antoine"

Revenons aux deux user stories que nous avons rédigées dans la leçon précédente pour le restaurant "Chez Antoine" :

1. Consulter la carte du restaurant
2. Ajouter un plat au panier

Votre mission : en vous mettant dans la peau d'un développeur qui doit réaliser ces fonctionnalités, essayez de les estimer. Prenez 10 minutes pour cet exercice.

1. Établissez une référence. C'est une étape cruciale. Décidons ensemble qu'une tâche très simple et bien connue, comme "Modifier le texte du pied de page", vaut 1 story point.
2. Estimez les deux stories. En utilisant la suite de Fibonacci (1, 2, 3, 5, 8...) et l'aide-mémoire plus haut, donnez une estimation pour chaque story.
3. Justifiez votre estimation. Pour chaque story, écrivez une ou deux phrases expliquant pourquoi vous avez choisi cette valeur. Pensez à la complexité (gestion de l'état du panier en React ?), à l'effort (création de plusieurs composants UI ?) et à l'incertitude (le design est-il clair ?).

Ma proposition d'estimation (à titre d'exemple)

Il n'y a pas de "bonne" réponse, car l'estimation est propre à chaque équipe. L'important est le raisonnement.

• Story 1 : Consulter la carte du restaurant

  • Estimation : 3 points
  • Justification : Cette tâche est plus complexe qu'un simple changement de texte (notre référence de 1 point). Elle implique de récupérer les données (probablement via une API), de créer des composants React pour les catégories et les plats, et de gérer l'affichage. Cependant, il n'y a pas d'interaction utilisateur complexe (c'est surtout de l'affichage), donc la complexité reste modérée.

• Story 2 : Ajouter un plat au panier

  • Estimation : 5 points
  • Justification : Cette story est plus complexe que la précédente. Elle inclut l'interaction utilisateur (clic sur un bouton), mais surtout, elle introduit la nécessité de gérer un état global : le panier. Sur le plan technique, cela signifie probablement mettre en place une logique de gestion d'état côté client (avec le Context API de React ou une librairie comme Redux/Zustand), mettre à jour plusieurs parties de l'interface (l'icône du panier, la quantité sur le plat) et potentiellement gérer des cas complexes (stock, options du plat, etc.). L'incertitude et la complexité sont donc plus élevées.

Conclusion

Félicitations ! Vous avez maintenant une compréhension solide de la manière dont les équipes agiles estiment le travail. Cette approche déplace le focus de la question "Quand sera-ce fini ?" (qui mène à des promesses fragiles) à la question "Quelle est la taille de ce travail par rapport aux autres ?" (qui mène à une planification adaptative et réaliste).

Points clés à retenir :

• Les Story Points sont une mesure relative de la complexité, de l'effort et du risque, et non une mesure de temps.
• Le Planning Poker est une cérémonie collaborative pour aligner la compréhension d'une tâche et arriver à une estimation partagée.
• Seule l'équipe de développement vote. L'avis des experts est bienvenu, mais "c'est celui qui fait, qui sait".
• La vélocité est la métrique clé qui connecte les estimations au planning. Elle mesure la capacité de l'équipe et permet de faire des prévisions.
• Ne jamais convertir les story points en heures ! Cela détruirait tout l'intérêt de l'abstraction et réintroduirait les biais que l'on cherche à éviter.

Maintenant que nous avons un backlog rempli de user stories estimées, une nouvelle question se pose : par où commencer ? Dans la prochaine leçon, nous apprendrons à prioriser un backlog de produit avec la méthode MoSCoW, afin de nous assurer que l'équipe travaille toujours sur ce qui apporte le plus de valeur.