##Le Bénéfice principal des points des histoires utilisateurs

Si les points des histoires utilisateurs correspondent à une estimation du temps (effort) impliqués à réaliser quelque chose, pourquoi ne pas estimer directement en heures ou en jours ? Finalement, pourquoi utiliser des points ?

Il y a plusieurs bonnes raisons d’estimer les éléments du backlog produit en points, et je les couvrent pleinement dans les cours vidéo l’Agile Estimation et planification, mais il y a une raison impérieuse qui, à elle seule, suffit à justifier l’utilisation de points.

Cela a à voir avec le roi Henri I, qui régna entre 1100 et 1135. Avant son règne, un “yard” était une unité correspondant à la mesure entre le nez d’une personne et le bout de ces doigts. Imaginez toute la confusion que cette distance a causé étant différente pour chaque personne.

Le roi Henry a finalement décidé qu’un yard serait toujours la distance entre le nez du roi et le bout de son pouce. Commode pour lui, mais aussi pratique pour tout le monde parce qu’il y avait maintenant une unité de mesure standard.

Vous pourriez apprendre que pour vous, un yard (tel que défini par le bras du roi) correspondait plus ou moins à votre bras. J’aurais appris la même chose avec mon bras. Et nous aurions tous une unité de mesure commune.

Pour les points des histoires utilisateurs c’est la même chose. Comme les yards anglais, ils permettent aux membres de l’équipe, avec différents niveaux de compétence, à communiquer et s’accordent sur une estimation. Par exemple, imaginons que vous et moi décidions d’aller courir. J’aime courir, mais je suis très lent. Vous, en revanche, êtes un coureur très rapide. Vous vous pointez devant un parcours et dites : “ Prenons ce parcours. Il faudra 30 minutes.”

J’ai l’habitude de prendre ce parcours mais, étant un coureur beaucoup plus lent que vous, je sais que cela me prend 60 minutes à chaque fois que je le prends. Et je vous dis que je vais prendre cette route avec vous, mais que cela prendra 60 minutes.

Et là, nous débattons : “30” “60” “30” “60”

Ça n’aboutit à rien. Peut-être que nous arriverons à un compromis que nous appelons “45 minutes”. Mais c’est peut-être la pire chose que nous pourrions faire. Nous avons en effet maintenant une estimation qui n’est bonne pour aucun des deux.

Aussi, au lieu de transiger sur 45, nous continuons à discuter. “30” “60” “30” “60”

Finalement, vous me dites : “Mike, c’est un parcours de 5 miles. Je peux courir en 30 minutes”.

Et je vous dis, “Je suis d’accord : c’est un parcours de 5 miles. Cela me prend 60 minutes.”

Le problème est que nous avons tous les deux raison. Vous pouvez vraiment courir en 30 minutes, et il va vraiment m’en falloir 60. Lorsque nous essayons de mettre une estimation du temps pour effectuer ce parcours en courant, nous constatons que nous ne pouvons pas, parce que nous travaillons (courrons) à des vitesses différentes.

Mais, lorsque nous utilisons une mesure plus abstraite, dans ce cas des miles, nous pouvons nous mettre d’accord. Vous et moi sommes d’accord : le parcours est de 5 miles. Nous différons seulement sur le temps qu’il faudra à chacun pour effectuer ce parcours en courant.

Les points des histoires utilisateurs ont la même finalité. Ils permettent aux personnes avec des compétences différents et des vitesses de travail différentes à se mettre d’accord. Au lieu d’un coureur rapide et lent, considérez deux développeurs de productivité différente.

Comme les coureurs, ces deux développeurs peuvent convenir qu’une histoire utilisateur donnée est de 5 points (au lieu de 5 miles). Le développeur rapide peut penser que c’est facile et qu’il faudra une journée de travail. Le développeur plus lent peut penser qu’il faudra deux jours de travail. Mais ils peuvent s’accorder et appeler cette estimation “5 points”, vu que le nombre de points attribués à la première histoire est assez arbitraire.

Ce qui est important est une fois qu’ils s’accordent à dire que la première histoire est de 5 points, nos deux développeurs peuvent alors s’entendre sur les estimations suivantes. Si le développeur rapide pense qu’une nouvelle histoire utilisateur peut prendre deux jours (deux fois son estimation pour l’histoire à 5 points), il estimera la nouvelle histoire à 10 points. Il en va de même du deuxième programmeur, s’il pense qu’il faudra quatre jours (deux fois plus longues que son estimation pour l’histoire à 5 points).

Ainsi, comme la distance entre le nez du roi Henri au bout de ses doigts, les points des histoires utilisateur permettent aux individus qui avancent dans leurs tâches à des vitesses différentes de s’accorder.

Mike Cohn a travaillé avec les plus grosses compagnies (Fortune 500), de petites startups et tout ce qu’il peut y avoir entre. Avec plus de 15 ans d’expérience de Scrum et d’agile, Mike a l’expertise nécessaire et des connaissances profondes pour aider votre organisation à créer des équipes performantes.

Auteur : Mike Cohn
Source : The Main Benefit of Story Points
Date de parution originale : 9 Septembre 2014

Traducteur : Sylvain Fraïssé
Date de traduction : 12/09/2014