En projet Agile, toute la planification se base sur l’estimation de la taille des User Story. Par ailleurs, la construction d’itérations équilibrées nécessite d’avoir des Story de taille suffisement petite. Quand le Product Backlog contient plusieurs dizaines voir quelques centaines de Story, estimer ces Story peut prendre un temps conséquent pour l’équipe. L’Affinity Estimating est une réunion structurée qui peut permettre, dans l’espace de 2 ou 3 heures de définir les tailles des Story d’un backlog de taille conséquente.
Qui doit participer ?
L’équipe, le Coach ainsi que le Product Owner et d’éventuels utilisateurs ou parties prenantes doivent être présentes. Les personnes présente du coté du Product Owner doivent connaître les Product Backlog suffisamment pour pouvoir donner à l’équipe les détails nécessaires.
Quelle durée ?
Une durée entre 2 à 3 heures doit être prévue.
Autres préparatifs
Les User Story du Product Backlog doivent être disponibles sous forme de cartes que l’on peut accrocher et déplacer sur un mur ou un tableau. Sur le tableau ou le mur de travail, une extrémité est marquée “Petite Story”, et l’autre “Grande Story”, de façon à ce que l’équipe identifie l’ordre dans lequel les Story sont sensées être triées. Par example, de gauche à droite de la plus petite à la plus grande.
Les étapes de la réunion
Chapter 1. Etape 1 : Classification silencieuse
Le Product Owner fournit à l’équipe le Product Backlog par Packet à l’équipe. Les membres de l’équipes vont placer et déplacer les Story sur le mur une à une dans l’ordre de taille. Pendant cette exercice l’équipe ne discute pas entre elle, cependant elle peut obtenir de la part du Prodcut Owner ou des utilisateurs les clarifications nécessaires sur les Story. Cette étape se termine quand plus personne n’a envie de bouger des Story. Elle peut aussi être “Time-boxée”, c’est à dire avoir une durée maximale pré-determinée, afin de maîtriser le temps de réunion. Une telle timebox peut être par exemple d’une heure.
Chapter 2. Etape 2 : Discussion de l’équipe
A cette étape, chaque membre de l’équipe peux changer l’ordre des Story sur le tableau mais doit pour cela en discuter et le justifier auprès de ses collègues. Cette étape se termine quand plus personne n’a envie de bouger des Story.
Chapter 3. Etape 3 : Mise en boite
Des colonnes sont tracées sur le tableau pour grouper les User Story par taille, chaque groupe ainsi crée contient les Story de la même taille dans l’échelle. L’échelle est celle définie par l’équipe, classiquement :
- La suite de fibonacci : 1; 2; 3; 5; 8; 13 …
- Les tailles : XS, S, M, L, XL
- Deux puissance N : 2, 4, 8, 16 …
Chapter 4. Etape 4 : Intervention du Product Owner et utilisateurs
L’équipe peut prendre une pause pendant que le Product Owner et autres utilisateurs présents marquent les Story dont il souhaitent rediscuter l’estimation avec une marque ou une couleur particulière.
Chapter 5. Etape 5 : Discussion avec le Product Owner
L’équipe et le Product Owner se concentrent sur les Story les plus prioritaires pour affiner ou confirmer la première estimation de taille.
Finalisation
Au bout de cette étapes les Stories du Product Product backlog on été triées et ont une taille associée. Certaines peuvent rester trop floues pour être estimées, elles nécessiteront par exemple un “Spike”, c’est à dire une étude exploratoire de 1 ou 2 jours pendant une itération, afin de lever les incertitudes et donner une estimation. D’autres seront d’une taille trop grosses pour être incluse dans une itération et devront être détaillées par le Product Backlog en plusieurs “Story” plus petites.