Story points et estimation

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 qui permettent aux Product Owners de prendre des décisions qui affecteront l'équipe entière, et toute l'entreprise. Avec un tel enjeu, il n'est pas surprenant qu'ils aient tous, des développeurs à la direction générale, des moments de stress intense à ce sujet. Mais c'est une erreur. L'estimation des story points 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.

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.

Il est primordial d'impliquer tous les membres de l'équipe (développeurs, designers, 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 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 !

Vous voulez essayer les story points ? Tout d'abord, inscrivez-vous ou connectez-vous à Jira

• Essayez ce tutoriel interactif pour configurer votre premier projet Scrum
• Apprenez à configurer les estimations de story point et suivez vos user stories

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 sont des unités de mesure qui permettent d'estimer l'effort global nécessaire pour implémenter intégralement une tâche du backlog produit ou autre. Les équipes assignent des story points en fonction de la complexité et du volume du travail, mais aussi du risque ou de l'incertitude. Des valeurs sont assignées pour mieux répartir le travail en petites tâches, afin de pouvoir faire face à l'incertitude. Au fil du temps, cela permet aux équipes de comprendre ce qu'elles peuvent accomplir sur une période donnée et d'établir un consensus et un engagement pour la solution. 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é.
• Lorsque vous êtes d'accord sur l'effort relatif lié à 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é.

Malheureusement, les story points sont souvent mal utilisés. Ils ne se déroulent pas correctement lorsqu'ils sont utilisés pour juger les gens, assigner des calendriers et des ressources de façon détaillée, et lorsqu'ils sont confondus avec une mesure de la productivité. Les équipes doivent plutôt les utiliser pour comprendre l'ampleur du travail et sa hiérarchisation. Pour une discussion approfondie sur les story points et les pratiques d'estimation, consultez cette table ronde avec des experts du secteur et poursuivez votre lecture pour des conseils d'estimation plus agiles.

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, 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 ?

• Installez l'app Planning Poker
• En savoir plus sur Planning Poker

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.

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 responsable produit un chiffre approximatif qui lui permettra de hiérarchiser la feuille de route du produit en conséquence.

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) assurent le suivi des story points, ce qui facilite considérablement la réflexion autour des estimations, ainsi que leur réétalonnage. Essayez, par exemple, de faire un pull des 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 ce n'est pas le cas, tentez de comprendre pourquoi. Utilisez ces informations lors des futures discussions sur l'estimation.

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