Story points et estimation

Une bonne estimation permet aux Product Owners d'optimiser l'efficacité et l'impact. C'est pourquoi elle est si importante. 

Dan Radigan Dan Radigan
Parcourir les rubriques

L'estimation est une tâche complexe. Pour les développeurs, c'est l'un des aspects les plus difficiles, si ce n'est le plus difficile, de leur travail. Il faut prendre en compte une kyrielle de facteurs permettant aux Product Owners de prendre des décisions qui affecteront l'équipe entière, et tout le business. Avec un tel enjeu, il n'est pas surprenant que tout le monde, des développeurs à la direction générale, connaisse des moments de stress intense à ce sujet. Mais c'est une erreur. L'estimation Agile n'est rien de plus qu'une évaluation. Ce n'est pas un serment par le sang. 

Il n'y a aucune obligation à travailler le week-end pour compenser la sous-estimation d'une tâche. Cela dit, voyons comment réaliser des estimations Agile aussi précises que possible, de différentes façons. 

Collaborer avec le responsable produit

Dans le développement Agile, le Product Owner a pour tâche de hiérarchiser le backlog, à savoir la liste des tâches contenant une brève description de l'ensemble des fonctionnalités et corrections souhaitées pour un produit. Le Product Owner recueille les exigences du business, mais ne comprend pas toujours les détails de l'implémentation. C'est pourquoi une bonne estimation peut lui apporter une nouvelle perspective quant aux efforts que requiert chaque tâche. Cela se reflète ensuite dans son évaluation de la priorité relative de chaque tâche.

Lorsque l'équipe d'ingénierie commence son processus d'estimation, des questions émergent généralement autour des exigences et des user stories. Et c'est positif : ces questions permettent à l'ensemble de l'équipe d'appréhender le travail de façon plus complète. S'agissant plus précisément des Product Owners, la subdivision des tâches en estimations et opérations granulaires leur permet de hiérarchiser via des story points tous les aspects du travail (y compris ceux qui sont éventuellement masqués !). Une fois qu'ils disposent des estimations de l'équipe de développement, il n'est pas rare pour un Product Owner de réorganiser les tâches du backlog. 

L'estimation agile est un sport d'équipe

Il est primordial d'impliquer tous les membres de l'équipe (développeurs, concepteurs, testeurs, déployeurs... tous). Chacun d'eux porte un regard différent sur le produit et le travail requis afin de livrer une user story. Par exemple, si la gestion de produit pose une exigence qui, à première vue, semble simple, comme la prise en charge d'un nouveau navigateur web, les équipes de développement et de QA doivent intervenir. En effet, grâce à leur expérience, elles seront en mesure d'identifier les problèmes potentiellement sous-jacents.

De même, les changements de conception nécessitent non seulement l'avis des concepteurs, mais celui des équipes de développement et de QA. Lorsqu'une partie de l'équipe produit élargie est écartée du processus d'estimation, les estimations sont de moindre qualité, le moral est moins bon parce que certains contributeurs clés se sentent exclus, et la qualité du logiciel en pâtit.

Par conséquent, ne laissez pas votre équipe tomber dans le piège d'une estimation réalisée dans l'absolu. C'est une voie rapide vers l'échec ! 

Story points et estimation horaire

Les équipes de développement traditionnelles réalisent leurs estimations en temps : jours, semaines, mois. En revanche, beaucoup d'équipes Agile sont passées aux story points. Les story points notent l'effort relatif du travail selon la suite de Fibonacci : 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Cela peut sembler tout sauf intuitif. Pourtant, cette abstraction est utile puisqu'elle pousse l'équipe à prendre des décisions plus radicales en ce qui concerne la difficulté du travail. Voici quelques bonnes raisons d'opter pour les story points :

  • Les dates ne prennent pas en compte le travail non lié au projet qui se faufile, de façon inévitable, dans notre quotidien : e-mails, réunions et entretiens qui impliquent un membre de l'équipe.
  • Les dates présentent un caractère émotionnel. Une estimation relative élimine tout attachement affectif.
  • Chaque équipe réalise une estimation du travail selon une échelle légèrement différente, ce qui signifie que sa vélocité (mesurée en points) sera naturellement différente. Dans un tel contexte, il est impossible d'argumenter en brandissant l'arme de la vélocité.
  • Lorsque vous êtes d'accord sur l'effort relatif de la valeur de chaque story point, vous pouvez assigner rapidement des points sans grande discussion. 
  • Les story points récompensent les membres de l'équipe qui résolvent des problèmes en fonction de leur difficulté et non du temps passé. Ainsi, les membres de l'équipe restent concentrés sur la livraison de valeur, et non sur le temps consacré. 

Story points et planning poker

Les équipes qui débutent avec les story points adoptent une pratique intitulée « planning poker ». Chez Atlassian, le planning poker est une pratique courante à tous les échelons de l'entreprise. L'équipe prend une tâche du backlog, en discute brièvement et chaque membre de l'équipe formule mentalement une estimation. Ensuite, chacun brandit une fiche où est inscrit le chiffre reflétant son estimation. Si tout le monde est d'accord, tant mieux ! Dans le cas contraire, prenez un peu de temps (mais pas trop, juste quelques minutes) pour comprendre le raisonnement sur lequel s'appuient les différentes estimations. Mais n'oubliez pas, les estimations doivent rester une activité globale. Si l'équipe va trop loin dans le détail, respirez profondément et relevez le niveau de la discussion.

Prêt à essayer ? 

Des estimations plus intelligentes, pas plus difficiles

Aucune tâche individuelle ne doit durer plus de 16 heures. (Si vous utilisez des story points, vous pouvez, par exemple, décider de fixer la limite supérieure à 20 points.) Les tâches plus longues sont difficiles à évaluer de façon réellement fiable. Or, cette fiabilité est particulièrement importante pour les tâches figurant en tête du backlog. Lorsque l'estimation d'une tâche dépasse le seuil des 16 heures (ou des 20 points), cela signifie qu'il faut la subdiviser en tâches plus granulaires et procéder à une nouvelle estimation.

Pour les tâches situées plus bas dans le backlog, les estimations peuvent être plus grossières. Lorsque l'équipe commencera concrètement à travailler sur ces tâches, les exigences auront peut-être évolué. Et votre application, elle, aura certainement changé. Les estimations antérieures ne seront donc plus aussi exactes. Ne perdez pas de temps à estimer des tâches qui vont probablement évoluer. Fournissez simplement au Product Owner un chiffre approximatif qui lui permettra de hiérarchiser la feuille de route produit en conséquence.

Apprendre des estimations antérieures

La rétrospective correspond au moment où l'équipe intègre les informations issues des itérations antérieures, y compris la précision des estimations. Beaucoup d'outils Agile (tels que Jira Software) assurent le suivi des story points, ce qui facilite considérablement la réflexion autour des estimations, ainsi que leur recalibrage. Essayez, par exemple, d'extraire les cinq dernières user stories que l'équipe a livrées avec la valeur de story point 8. Discutez-en pour déterminer si le niveau d'effort consacré à toutes ces tâches est similaire. Si tel n'est pas le cas, tentez de comprendre pourquoi. Utilisez ces informations lors des futures discussions et estimations.

Comme tous les autres aspects d'Agile, l'estimation exige de la pratique. Avec le temps, vous ne cesserez de vous améliorer. 

suivant
Metrics