Voir la source de Pourquoi c'est bien d'arrondir certaines estimations

[[Category: Mike Cohn]]
[[Category: Portail Exactimation]]
<div id="content_view" class="wiki" style="display: block"><span style="background-color: #ffffff">Auteur : Mike Cohn</span><br /> <span style="background-color: #ffffff">Source : </span>Why Rounding Up Some Estimates Is Good<br /> <span style="background-color: #ffffff">Date : 08/09/2016</span><br />
----
<span style="background-color: #ffffff">Traducteur : Fabrice Aimetti</span><br /> <span style="background-color: #ffffff">Date : 08/09/2016</span><br />
----
''<span style="background-color: #ffffff">Traduction :</span>''<br /> <br /> [[Il%20vaut%20mieux%20penser%20aux%20estimations%20en%20point%20de%20story%20comme%20des%20intervalles|La dernière fois]], j'ai proposé de considérer les nombres que vous utilisez, pour faire vos estimations, comme des intervalles. Si vous utilisez 1, 2, 3, 5, 8, 13 et 20, par exemple, le 13 est utilisé pour les estimations entre 9 et 13. Et j'ai également dit que ces nombres pouvaient être vus comme des seaux d'eau.<br /> <br />  Vous avez peut-être lu cet article et avez été préoccupé par le fait qu'arrondir vers le haut les estimations pouvait mener à allonger artificiellement les délais. Je vais vous expliquer pourquoi ce n'est généralement pas le cas.<br /> <br />  Considérons un élément du backlog produit que vous estimez à 10 points. Sauf que vous utilisez la séquence modifiée de Fibonacci citée ci-dessus et appliquez la stratégie d'arrondi que je vous ai recommandée. Vous estimerez donc finalement cet élément du backlog produit à 13.<br /> <br />  Supposons ensuite qu'avec 13 points, cet élément soit trop gros pour entrer dans un sprint. L'équipe le découpe donc en plus petites stories ; par exemple en trois plus petites stories, estimées à 5, 5 et 2 points.<br /> <br />  Voyons ce qu'il arrive avec ces nombres.<br /> <br />  Ces trois petites stories représentent un total de 12 points. C'est 1 point en-dessous de l'estimation à 13 que vous avez faite pour la story de départ. Mais c'est deux points de plus que le 10 auquel vous aviez au début pensé comme étant la bonne estimation pour cette story de départ.<br /> <br />  En forçant l'estimation à entrer dans un seau plus gros, vous avez amélioré la probabilité de prédire correctement la date de livraison du projet.<br /> <br />  Si vous aviez arrondi vers le bas (estimation à 8), le projet ferait quatre points de moins. Si vous aviez utilisé votre estimation de départ (10), votre projet ferait deux points de moins.<br /> <br />  A la place, en estimant les valeurs dans des seaux et en arrondissant vers le haut, vous avez rendu plus probable le fait de livrer votre projet dans les temps.<br /> <br />  Mais est-ce que les 10 points de story n'auraient pas pu se transformer en 8 points ? Oui, mais cela aurait pu aussi se transformer en 14, 15 ou tout autre nombre.<br /> <br />  Le travail a tendance à s'étendre lorsqu'on regarde en détail. Lors de la première estimation de cet exemple, votre équipe avait mis 10 points. Mais lorsqu'elle a ré-estimé un peu plus tard, l'équipe a décidé de mettre 12 points. Ca arrive assez souvent.<br /> <br />  Si vous êtes Agile depuis un certain temps et que vous n'aviez jamais estimé avec des seaux de cette manière, vous avez dû rencontrer le type de situation que j'ai décrit.<br /> <br />  Par exemple, votre équipe a fait de gros progrès en un sprint et votre burndown chart le montre. Mais certains éléments du backlog produit ont été découpés durant le sprint et leurs estimations ont augmenté. Et donc votre burndown chart ne semble finalement pas aussi bon que ça pour ce sprint.<br /> <br />  De la façon dont je le décris, l'arrondi vers le haut ne correspond pas à étirer les délais. Cela reflète l'incertitude dans les estimations. Utiliser une approche d'estimation qui reflète cette incertitude vous aidera à réussir avec l'Agilité.<br /> <br />  Mike<br /> <br />  P.S. : considérer de cette façon chaque valeur estimée comme un intervalle peut aider votre équipe à atteindre un niveau de consensus. Après tout, si une personne pense que quelque chose vaut 7 et qu'une autre personne pense que c'est 8, elles estimeront toutes les deux que c'est 8 avec cette approche. Mais que se passe-t-il si la moitié de l'équipe pense que cela vaut 5 et que l'autre moitié pense que cela vaut 8 . Devrait-elle arrondir vers le haut ? vers le bas ? prendre la moyenne ? J'en parlerai [[Arrondi%20vers%20le%20haut%20%3F%20vers%20le%20bas%20%3F%20Comment%20obtenir%20le%20consensus%20pendant%20un%20Planning%20Poker%20%3F|la prochaine fois]].<br /> <br />