Estimer un backlog complet en se basant sur un échantillon
Auteur : Mike Cohn
Source : Estimating a Full Backlog Based on a Sample of It
Date : 16/09/2011
Traducteur : Fabrice Aimetti
Date : 18/09/2011
Traduction :
Je traite ici une question que l'on m'a posée récemment et que l'on me pose en fait une fois par mois. La question a à voir avec la façon dont nous estimons le nombre d'heures qu'il faudra pour livrer un backlog produit donné si nous n'avons pas du tout d'historique.
Mon premier conseil est de toujours essayer de remettre la réponse à plus tard, jusqu'à ce que vous soyez en mesure d'obtenir un historique, ne serait que sur un seul sprint. Mais ce n'est pas toujours possible. Ce n'est pas une recommandation, mais vous pouvez vous engager sur une ou plusieurs réunions de planification de sprints et les utiliser pour prévoir une vélocité probable.
Cependant, certaines personnes sont plus à l'aise lorsqu'elles pensent en heures plutôt qu'en prévoyant une vélocité. Elles veulent prévoir le nombre d'heures que prendra un backlog produit. De là, elles estimeront la durée du projet (ce qui pourrait être fait plus directement avec une estimation de la vélocité). Mais, puisque c'est une question fréquente, je tiens à la traiter.
Voici en gros la question qu'on m'a posée. J'ai paraphrasé, simplifié et laissé de côté les informations superflues :
Nous n'avons pas d'historique sur notre vélocité. Nous avons un backlog produit de 300 user stories. Chaque user story a été estimée, la plupart dans un intervalle de 3 à 13 points.
L'approche suivante serait-elle raisonnable selon vous ?
- Prendre un échantillon aléatoire de 40 stories.
- Décomposer chacune de ces stories en tâches et estimer ces tâches.
- De cette estimation des tâches, en déduire un nombre moyen d'heures par story.
Par exemple, supposons que les 40 user stories sélectionnées au hasard fassent un total de 150 points et que les tâches identifiées pour ces 40 user stories fassent un total de 600 heures. Nous avons donc en théorie environ 4 heures par point de story ?
Eh bien, l'idée présentée illustre très bien deux problèmes :
- Il est important de se rappeler que la relation entre les points et les heures n'est pas une relation d'équivalence. On n'a pas 1 point qui équivaut à 4 heures (ce que notre exemple a montré ci-dessus). C'est plutôt que 1 point équivaut à une moyenne de quatre heures avec un écart type disons de plus ou moins 45 minutes. Cela voudrait dire que dans la plupart des cas (68% du temps) la relation serait que 1 point prend de 3h15 à 4h45 pour être traité. Cela voudrait donc dire que presque toujours (98% du temps), un point prendrait entre 2h30 et 5h30 pour être traité (deux écarts-types).
- L'approche ci-dessus suppose que 1 point de story et 13 points de story sont estimés parfaitement relativement l'un par rapport à l'autre. En d'autres termes, elle suppose que si la durée moyenne d'une story d'un point est de 4 heures, la moyenne d'une story de 13 points sera de 13×4=52 heures. Pour de nombreuses raisons, il est peu probable que cela soit vrai. Et les données que j'ai recueillies auprès de nombreuses équipes, montre, comme nous nous y attendions, que les équipes ne sont pas parfaites, même si beaucoup d'entre elles sont étonnamment cohérentes.
Alors, que pouvons-nous faire pour remédier à ces problèmes ? Une première amélioration vraiment très simple est de calculer le nombre moyen d'heures pour des stories de la même taille plutôt qu'une moyenne globale. Par exemple, dans l'exemple ci-dessus, nous avons dit que les 40 stories valaient 150 points au total et 600 heures pour une moyenne de 4 heures par point. Mais, si l'on fait la moyenne des stories de 1 point, nous constatons qu'elles valent 3,2 heures par point, et que les stories de 2 points qui ont été décomposées en plusieurs tâches valent 4,3 heures par point, et que les stories de 3 points valent 4,1 heures, et ainsi de suite.
Nous pouvons alors multiplier ce nombre moyen d'heures par le nombre de stories du backlog produit qui ont la taille correspondante. Un exemple est donné dans le tableau suivant en utilisant la moyenne des heures indiquées ci-dessus :
| Points |
Heures par story |
Nb. de stories |
Total des heures |
|---|---|---|---|
| 1 |
3,2 |
5 |
16,0 |
| 2 |
8,6 |
8 |
68,8 |
| 3 |
12,3 |
7 |
86,1 |
D'abord, vous remarquerez que la deuxième colonne représentent les heures par story, et non des heures par point. On suppose que les stories de deux points prennent 4,3 heures par point, soit 8,6 (4,3x2) heures par story comme indiqué dans cette colonne.
Ce tableau montre que nous avons cinq user stories de 1 point. Chacune est censée être d'environ 3,2 heures, donc nous nous attendons à passer 16 heures au total sur les stories de 1 point. En additionnant la dernière colonne de ce tableau, nous obtenons un total attendu de 170,9 heures.
Notez que cette approche est sujette à toutes les imperfections qui ont été introduites lors de l'identification des tâches et de l'étape d'estimation. Surtout que l'équipe n'est pas parvenue à identifier toutes les tâches. Donc, cette approche permettra d'estimer le nombre d'heures permettant de livrer les tâches identifiées. Certains ajustements devront être faits pour estimer la quantité de travail que l'équipe n'est pas parvenue à identifier et pour ajuster en conséquence la durée du projet.
Je proposerai d'autres améliorations à cette approche simple lors de prochains billets.
