Comment estimer une histoire utilisateur à l’aide d’un tableau d’affinité automatisé

Points d’histoire ou jours, ou les deux ?

Les gens discutent souvent de savoir s’il faut utiliser des points d’histoire ou des heures (ou des jours) pour l’estimation des histoires. Certaines personnes pensent que nous n’avons pas besoin de calculer les points d’histoire ni la vitesse d’équipe. En effet, différentes équipes peuvent avoir des opinions différentes, mais malgré tout, la plupart des projets Agile effectuent bien l’estimation des histoires et la considèrent comme l’un des outils très utiles pour mener les projets à temps et dans les délais budgétaires.

Tableau d’affinité pour l’estimation des histoires

Dans Visual Paradigm, nous ne considérons pas l’estimation des histoires comme un processus conflictuel ou négocié, mais comme un processus de construction d’équipe qui rend la collaboration sur les tâches et la charge de travail claire et transparente pour tous les membres de l’équipe. L’outil d’histoire utilisateur permet à l’équipe d’utiliser le tableau d’affinité pour automatiser le processus d’estimation des histoires, ainsi que l’élimination des pics. De plus, le tableau d’affinité visuel permet une estimation en temps réel avec à la fois les points d’histoire et les heures d’histoire simultanément. Lorsque vous faites glisser une histoire sur le tableau, les points d’histoire et les heures s’affichent simultanément pendant que l’histoire se déplace. Il suffit de déposer l’histoire dans la case où votre équipe estime que l’estimation est appropriée.

Comment le tableau d’affinité calcule-t-il ?

Pour comprendre comment les points d’histoire et les jours sont estimés automatiquement dans le tableau d’affinité, nous devons comprendre que les grilles horizontales représentent l’effort de travail, qui augmente de gauche à droite, et que la complexité du développement de l’histoire (comme de nouvelles technologies, de nouveaux domaines, etc.) augmente du haut vers le bas.

Comme le nombre maximum de jours pour développer une histoire utilisateur ne devrait pas dépasser la durée du sprint (sinon, soit l’histoire est trop grande et doit être divisé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 base, l’estimation des histoires peut être calculée automatiquement.

Affinité des histoires utilisateurs pour l’estimation

L’estimation d’une histoire 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 une estimation sur quelques histoires que nous jugeons les plus confortables à estimer (par exemple, 5 jours avec un niveau de certitude moyen). Dans ce cas, vous placerez l’histoire au milieu verticalement (niveau de certitude ou de risque) et horizontalement (l’effort de travail équivaut à 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 histoires. Demandez-vous si cette histoire 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 d’histoires sur le tableau d’affinité, vous pouvez les comparer entre elles pour déterminer si l’équilibre est logique, 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 conflits. La précision s’améliore généralement à mesure que l’équipe devient plus mature.

Éliminer les risques grâce au pic 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 qu’à produire un produit livrable. 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 prenons pas seulement en compte l’effort de développement, mais aussi les risques et incertitudes associés. Très souvent, un pic est créé avant le début officiel d’un sprint afin de gérer le travail nécessaire à effectuer pour que certaines autres histoires puissent être estimées de manière équitable.