Estimation de la story utilisateur – Tableau d’affinité

Comment estimer les stories utilisateurs pour le développement agile

Estimer une story utilisateur est difficile ! Comment pouvons-nous obtenir la meilleure estimation de la taille d’une story ? Certaines personnes disent que la meilleure taille doit être estimée en points de story, tandis que d’autres préfèrent qu’elle soit estimée en heures ou en jours.

Bien sûr, l’estimation est certainement difficile, mais il existe quelques concepts qui peuvent nous aider dans le processus d’estimation des stories utilisateurs :

1. Estimez les stories utilisateurs en termes relatifs selon deux aspects
   • Effort de travail
   • Risque (par exemple, complexité et incertitude)
2. Estimez les stories utilisateurs à l’aide de points de story
3. Placez ces stories utilisateurs dans le tableau d’affinité pour lesquelles vous avez une plus grande confiance dans l’estimation en termes d’effort de travail et de complexité (risque)
4. Estimez progressivement les autres types de stories moins familières en termes d’effort de travail et de complexité en les comparant avec celles qui ont déjà été estimées dans le tableau d’affinité.

Affinité des stories utilisateurs pour l’estimation

L’estimation d’une story utilisateur ne peut jamais être à 100 % précise, et en réalité aucune méthode ne peut y parvenir. Pour améliorer la précision de l’estimation, nous commençons par décider de la durée du sprint (par exemple, deux semaines ou 10 jours ouvrés) et effectuons l’estimation sur quelquesstories utilisateursque nous sentons le plus à l’aise à estimer (par exemple, 5 jours et la certitude est moyenne). Dans ce cas, vous placerez la story au milieu verticalement (certitude ourisqueniveau) et horizontalement (effort de travaileffortest égal à 5 jours, soit la moitié de la durée du sprint, soit 10 jours). Vous pouvez ensuite l’utiliser comme point de référence pour estimer les autres stories utilisateurs. Demandez-vous si cette story utilisateur nécessite plus d’effort que celle de référence, ou moins, et si elle comporte plus ou moins d’incertitude. En plaçant davantage de stories sur le tableau d’affinité, vous pouvez les comparer entre elles pour déterminer si les écarts sont logiques ou non, puis les ajuster pour les rendre équitables. Le processus est un peu plus une question d’art que d’ingénierie. Faites-le et discutez-en lors de la réunion d’équipe plutôt que de provoquer des confrontations. La précision s’améliore généralement à mesure que l’équipe devient plus mature.

Comment le tableau d’affinité calcule-t-il ? (Regarder une vidéo) 

Pour comprendre comment les points de story et les jours sont estimés automatiquement dans le tableau d’affinité, nous devons comprendre que les grilles horizontales représentent les efforts de travail, qui augmentent de gauche à droite, et que la complexité du développement de la story (par exemple, nouvelle technologie, nouveau domaine, etc.) augmente du haut vers le bas.

Comme le nombre maximum de jours pour développer une story utilisateur ne devrait pas dépasser la durée dusprint (sinon, soit la story est trop grande et doit être décomposée, soit le sprint est trop court et nécessite un allongement), le nombre de jours de la grille en bas à droite doit également être égal à la durée du sprint. Sur cette hypothèse, l’estimation de la story peut être calculée automatiquement.

Notez que : dans l’exemple ci-dessus

Point de story = Effort x Risque (par exemple, 3 x 4 = 12)

Unité de point de story = Nombre total de points / Durée du sprint (par exemple, 100 / 20) = 0,2

Jours (heures) de story = Point de story / Unité de point de story (par exemple, 12 x 0,2) = 2,4

Éliminer les risques avec un spike de projet

Selon le dictionnaire Agile, la définition de Spike est :

« Une tâche visant à répondre à une question ou à recueillir des informations, plutôt que de produire un produit. Parfois, une histoire utilisateur est générée qui ne peut pas être correctement estimée avant que l’équipe de développement ne réalise un travail concret pour résoudre une question technique ou un problème de conception. La solution consiste à créer un « spike », qui est un travail dont le but est de fournir la réponse ou la solution.»

Lors de l’estimation d’une histoire utilisateur, nous ne considérons pas seulement l’effort de développement, mais aussi les risques et incertitudes impliqués. Souvent, un spike est créé avant le début formel d’un sprint afin de gérer le travail à effectuer pour permettre une estimation équitable d’autres histoires utilisateurs.

Téléchargez et essayez maintenant !