Les secrets derrière les story points et l'estimation Agile

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

Dan Radigan Dan Radigan

Estimation is hard. For software developers, it's among the most difficult–if not the most difficult–aspects of the job. It must take into account a slew of factors that help product owners make decisions that affect the entire team–and the business. With all that at stake, it's no wonder everyone from developers to upper management is prone to getting their undies in a bunch about it. But that's a mistake. Agile estimation is just that: an estimate. Not a blood-oath. 

There's no requirement to work weekends in order to compensate for under-estimating a piece of work. That said, let's look at some ways to make agile estimates as accurate as possible.  

Collaborating with the product manager

In agile development, the product manger is tasked with prioritizing the backlog–the ordered list of work that contains short descriptions of all desired features and fixes for a product. Product owners capture requirements from the business, but they don’t always understand the details of implementation. So good estimation can give the product manager new insight into the level of effort for each work item, which then feeds back into their assessment of each item's relative priority.

When the engineering team begins its estimation process, questions usually arise about requirements and user stories. And that's good: those questions help the entire team understand the work more fully. For product managers specifically, breaking down work items into granular pieces and estimates via story points helps them prioritize all (and potentially hidden!) areas of work. And once they have estimates from the dev team, it's not uncommon for a product owner to reorder items on the backlog. 

L'estimation agile est un sport d'équipe

Involving everyone (developers, designers, testers, deployers... everyone) on the team is key. Each team member brings a different perspective on the product and the work required to deliver a user story. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Likewise, design changes require not only the design team's input, but that of development and QA as well. Leaving part of the broader product team out of the estimation process creates lower quality estimates, lowers morale because key contributors don't feel included, and compromises the quality of the software.

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 traditionnelles de développement de logiciels réalisent leurs estimations en temps : jours, semaines, mois. En revanche, beaucoup d'équipes agiles 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 inonde, de façon inévitable, 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 sur une échelle légèrement différente, ce qui signifie que leur 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é.
  • Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
  • Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

Story points and planning poker

Les équipes qui débutent avec les story points appliquent 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, discute brièvement de cette tâche 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.

Ready to give it a try? 

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 diviser en tâches plus granulaires et procéder à une nouvelle estimation.

For items deeper in the backlog, give a rough estimate. By the time the team actually begins to work on those items, the requirements may change, and your application certainly will have changed. So prior estimates won’t be as accurate. Don’t waste time estimating work that is likely to shift. Just give the product manager a ballpark figure she can use to prioritize the product roadmap appropriately.

Apprendre des estimations antérieures

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Many agile tools (like Jira Software) track story points, which makes reflecting on and re-calibrating estimates a lot easier. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why. Use that insight in future estimation discussions.

Like everything else in agile, estimation is a practice. You'll get better and better with time.