Story Points sans estimations du Sprint Backlog avec des Task Points

Lorsque j'ai écrit le livre Agile Estimating and Planning en 2005, je m'intéressais déjà depuis cinq ans à différentes méthodes d'estimation. Après avoir mené des expériences avec plusieurs équipes – en particulier celles qui travaillaient directement pour moi – j'avais le sentiment d'en avoir suffisamment appris pour pouvoir écrire ce livre.

Cependant, il y avait encore beaucoup de choses que je ne savais pas (et c'est toujours le cas aujourd'hui !). C'est pourquoi j'ai cherché des équipes qui estimaient et planifiaient leurs projets différemment de moi. Certaines de ces équipes utilisaient, en plus des Story Points, des Task Points pour estimer leurs Product Backlog Items.

J'ai trouvé cela intéressant. À l'époque, j'étais déjà un partisan des Story Points – et depuis, je suis devenu un fan encore plus convaincu grâce aux avantages des Story Points. Cependant, je ne comprenais tout simplement pas pourquoi une équipe utiliserait des Task Points. Mais étant un si grand fan des Story Points, je voulais en savoir plus sur les équipes qui travaillaient avec des Task Points.

J'ai réussi à convaincre quelques équipes de me laisser les observer, afin d'en apprendre davantage de cette manière.

Ce que j'ai découvert a confirmé mon hypothèse : les équipes ne devraient pas évaluer leurs Sprint Backlog Items avec des Task Points.

Le principal avantage des Story Points

L'avantage principal des Story Points est que des personnes avec des compétences variées, différents niveaux d'expérience et des parcours divers peuvent donner ensemble une estimation de leur travail.

Prenons un exemple un peu fantaisiste et imaginons que je veuille estimer avec une pieuvre l'effort nécessaire pour laver ma voiture.

Une pieuvre a quatre fois plus de bras que moi. Elle devrait donc pouvoir laver ma voiture quatre fois plus vite que moi. (Je t'avais prévenu que c'était un exemple à ne pas prendre trop au sérieux. Mais attends la suite.)

La pieuvre pourra aussi laver n'importe quelle autre voiture quatre fois plus vite que moi. La pieuvre et moi pouvons donc nous mettre d'accord pour attribuer environ cinq Story Points à ma petite voiture deux places et dix points à une voiture un peu plus grande.

Les Story Points permettent donc à la pieuvre et à moi de nous accorder sur un certain nombre de points – même si la pieuvre est certainement bien plus rapide que moi.

Points de tâche

Dans les équipes que j'ai observées, j'ai remarqué qu'un Task Point correspondait presque à un Story Point. Cependant, toutes les équipes avec lesquelles j'ai échangé souhaitaient utiliser une unité plus petite que les Story Points.

Par exemple, une équipe qui réalise dix Story Points par Sprint pourrait accomplir environ 80 Task Points par Sprint.

Les équipes voulaient simplement une unité plus petite et plus fine pour mieux suivre leur progression. C'est un peu comme si le compteur de vitesse de ta voiture affichait la vitesse en années-lumière par heure. De cette façon, il me serait difficile de savoir si je respecte la limite de vitesse ou non.

Utiliser des unités plus fines était une bonne idée pour de nombreuses équipes. Après tout, il est assez difficile de mesurer la progression quotidienne d'une équipe avec des Story Points quand elle réalise par exemple sept Story Points en deux semaines. Dans ce cas, les Story Points sont tout simplement une unité trop grande pour être utile.

Qu'en est-il des heures ?

Il existe cependant une unité plus fine avec laquelle chaque membre de l'équipe est déjà familier : les heures.

En observant les équipes estimer avec des Task Points, j'ai remarqué que cela n'apportait aucun avantage par rapport à l'estimation des éléments du Sprint Backlog en heures.

Il y a une différence fondamentale entre les éléments du Product Backlog (généralement sous forme de User Stories) et les tâches du Sprint Backlog : sur un élément du Product Backlog travaillent généralement trois à cinq personnes ; peut-être un ou deux développeurs, un testeur et éventuellement un designer, architecte, analyste ou rédacteur technique, etc. Sur une tâche, normalement, une seule personne travaille.

Cela signifie que tous les membres d'une équipe n'ont pas besoin de donner ensemble une estimation pour une tâche, comme ce serait le cas pour un élément du Product Backlog. Chacun dans l'équipe a la possibilité de donner une estimation pour la tâche, mais seule la personne qui travaillera finalement sur cette tâche peut fournir l'estimation définitive.

Si très probablement une seule personne travaillera sur une tâche, alors on devrait prendre l'estimation de cette personne pour la tâche. Si deux ou trois personnes travailleront sur une tâche, on laisse soit les trois donner ensemble une estimation, soit on prend l'estimation de la personne qui accomplira le plus probablement le travail.

Si le travail est transmis à une autre personne pendant le Sprint, dans le pire des cas, les estimations changeront simplement. Si un membre de l'équipe plus rapide reprend le travail d'un collègue plus lent, il modifie l'estimation de huit à quatre points – ou inversement.

Pourquoi pas de Task Points ?

Les Task Points n'ont donc aucun avantage par rapport aux heures. Ils présentent cependant des inconvénients par rapport aux Story Points :
- De nombreux membres de l'équipe ne les connaissent pas.
- Il est nécessaire d'avoir des valeurs de référence pour pouvoir faire des estimations.
- Il y a un risque que les estimations ne s'orientent plus sur les valeurs de référence initiales au fil du temps.

Mon conseil pour gérer les Task Points

J'ai terminé mon incursion dans le monde des Task Points sans avoir été convaincu de leur valeur. Je reste un partisan du Sprint Planning orienté engagement, tel que nous le connaissons. Peut-être que Sprint Planning orienté capacité serait une meilleure appellation. À mon avis, il présente des avantages considérables par rapport au Sprint Planning orienté vélocité.

Pour la plupart des équipes, le Sprint Planning orienté engagement ou capacité fonctionne mieux avec des heures. Certaines équipes suivent ce processus, mais omettent les estimations et ne les utilisent qu'en réunion pour déterminer ce qu'elles peuvent intégrer dans le Sprint.

D'autres équipes n'estiment tout simplement pas les éléments du Sprint Backlog. Chacune de ces approches peut bien fonctionner une fois qu'une équipe a acquis de l'expérience.

Je suis content d'avoir mené ce projet pour en apprendre davantage sur les Task Points et les équipes qui les utilisent.

Quand j'examine des méthodes alternatives d'estimation, je suis toujours un peu déçu quand une nouvelle approche ne s'avère pas meilleure qu'une existante. Mais c'est malheureusement assez souvent le cas.

Et pourtant, nous trouverons les améliorations continues que chaque agiliste recherche, si nous considérons autant d'options différentes que possible.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en français.

Product Owner : Missions & Défis

=> Découvre ce qu'un Product Owner fait de ses journées.

Qu'est-ce qu'une Story Scrum ?

=> Tu trouveras ici les différences entre User Stories, Epics et Themes.