Comment empêcher l'inflation des estimations - Historique des versions

Fabrice Aimetti le 23 avril 2020 à 17:46

Fabrice Aimetti — Thu, 23 Apr 2020 17:46:49 GMT

← Version précédente		Version du 23 avril 2020 à 17:46
Ligne 12 :		Ligne 12 :
	[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png\|link=]]<br />		[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png\|link=]]<br />
	<br/>		<br/>
	J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''		J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg\|link=]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg\|link=]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg\|link=]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Fabrice Aimetti le 23 avril 2020 à 17:46

Fabrice Aimetti — Thu, 23 Apr 2020 17:46:16 GMT

← Version précédente		Version du 23 avril 2020 à 17:46
Ligne 10 :		Ligne 10 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br />		[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png\|link=]]<br />
	<br/>		<br/>
	J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''		J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Fabrice Aimetti le 28 août 2018 à 18:13

Fabrice Aimetti — Tue, 28 Aug 2018 18:13:02 GMT

← Version précédente		Version du 28 août 2018 à 18:13
Ligne 10 :		Ligne 10 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
	[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br /> J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''		[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br />
			<br/>
			J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Fabrice Aimetti le 28 août 2018 à 18:12

Fabrice Aimetti — Tue, 28 Aug 2018 18:12:33 GMT

← Version précédente		Version du 28 août 2018 à 18:12
Ligne 1 :		Ligne 1 :
	[[Category: Mike Cohn]]		[[Category: Mike Cohn]]
	[[Category: Portail Exactimation]]		[[Category: Portail Exactimation]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Mike Cohn<br /> Source : [https://www.mountaingoatsoftware.com/blog/how-to-prevent-estimate-inflation How to Prevent Estimate Inflation]<br /> Date : 03/05/2016<br />		Auteur : Mike Cohn<br />
			Source : [https://www.mountaingoatsoftware.com/blog/how-to-prevent-estimate-inflation How to Prevent Estimate Inflation]<br />
			Date : 03/05/2016<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 19/07/2017<br />		Traducteur : Fabrice Aimetti<br />
			Date : 19/07/2017<br />
	----		----
	''Traduction :''<br /> <br /> [[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br /> J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''		Traduction :<br />
			<br />
			[[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br /> J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Fabrice Aimetti le 1 juillet 2018 à 10:50

Fabrice Aimetti — Sun, 01 Jul 2018 10:50:12 GMT

← Version précédente		Version du 1 juillet 2018 à 10:50
Ligne 5 :		Ligne 5 :
	Traducteur : Fabrice Aimetti<br /> Date : 19/07/2017<br />		Traducteur : Fabrice Aimetti<br /> Date : 19/07/2017<br />
	----		----
	''Traduction :''<br /> <br /> [[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br /> J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [/Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile Planning Poker (fr)]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''		''Traduction :''<br /> <br /> [[Image:how-to-prevent-estimate-inflation-quote.png\|how-to-prevent-estimate-inflation-quote.png]]<br /> J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé.<br /> <br /> Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer.<br /> <br /> La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story.<br /> <br /> L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points.<br /> <br /> '''<span style="font-size: 110%">Pourquoi l'inflation des estimations apparaît-elle ?</span>'''<br /> <br /> Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe.<br /> <br /> La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité.<br /> <br /> [[Image:compare-the-item-being-estimated_quote.jpg\|compare-the-item-being-estimated_quote.jpg]]<br /> <br /> Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [[Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile\|Planning Poker (fr)]]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet.<br /> <br /> A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois.<br /> <br /> Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq.<br /> <br /> Et donc cette story a été estimée à cinq.<br /> <br /> Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit.<br /> <br /> Et c'est comme cela que l'inflation des estimations survient.<br /> <br /> '''<span style="font-size: 110%">Comment empêcher l'inflation des estimations ?</span>'''<br /> <br /> J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire.<br /> <br /> Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''.<br /> <br /> Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant :<br /> <br /> [[Image:Triangulating-003.jpeg\|Triangulating-003.jpeg]]<br /> ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.''<br /> <br /> Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations.<br /> <br /> Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant.<br /> <br /> Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant :<br /> <br /> [[Image:Triangulating-004.jpeg\|Triangulating-004.jpeg]]<br /> ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.''<br /> <br /> Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois.<br /> <br /> '''<span style="font-size: 110%">La triangulation arrête l'inflation des estimations</span>'''<br /> <br /> La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations.<br /> <br /> Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points.<br /> <br /> Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points.<br /> <br /> '''<span style="font-size: 110%">Il existe encore un meilleur moyen d'empêcher l'inflation des estimations</span>'''<br /> <br /> Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus.<br /> <br /> '''<span style="font-size: 110%">Qu'en pensez-vous ?</span>'''<br /> <br /> ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation
Auteur : Mike Cohn
Source : [https://www.moun... »

Fabrice Aimetti — Sun, 01 Jul 2018 10:49:40 GMT

Page créée avec « Category: Mike Cohn Category: Portail Exactimation <div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cohn Source : [https://www.moun... »

Nouvelle page

[[Category: Mike Cohn]]
[[Category: Portail Exactimation]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cohn Source : [https://www.mountaingoatsoftware.com/blog/how-to-prevent-estimate-inflation How to Prevent Estimate Inflation] Date : 03/05/2016 
----
Traducteur : Fabrice Aimetti Date : 19/07/2017 
----
''Traduction :'' [[Image:how-to-prevent-estimate-inflation-quote.png|how-to-prevent-estimate-inflation-quote.png]] J'ai discuté avec un ScrumMaster récemment qui m'a dit que son équipe avait presque doublé sa vélocité en seulement deux mois. Plutôt que d'en être heureux, il était préoccupé. Il savait que l'équipe n'était pas soudainement devenue deux fois plus productive. En réalité, il doutait même que l'équipe soit plus rapide. Même si sa vélocité semblait le montrer. La cause de cette soudaine et dramatique augmentation était liée à l'inflation des points de story. Ou, dit autrement, à l'inflation des estimations, puisque le problème peut apparaître avec des unités d'estimation et pas uniquement des points de story. L'inflation des estimations apparaît lorsque l'estimation associée à un élément du backlog produit (généralement une user story) augmente dans le temps. Par exemple, aujourd'hui l'équipe estime quelque chose à cinq points sachant qu'auparavant elle l'aurait estimé à trois points. '''Pourquoi l'inflation des estimations apparaît-elle ?''' Il y a quelques causes possibles à l'inflation des estimations. L'une des plus communes est une pression excessive sur l'équipe pour qu'elle améliore ou livre plus de points par sprint. Cela provient souvent des dirigeants ou potentiellement des parties prenantes en dehors de l'équipe qui mettent la pression sur l'équipe. La vélocité est devenue un indicateur réellement tentant (mais mauvais) dans ce cas et l'équipe est poussée à démontrer qu'elle ira plus vite en augmentant la vélocité. [[Image:compare-the-item-being-estimated_quote.jpg|compare-the-item-being-estimated_quote.jpg]] Lorsqu'une équipe est sous pression pour augmenter sa vélocité, les membres de l'équipe vont souvent commencer à arrondir vers le haut leurs estimations pendant les réunions d'estimation des points de story (souvent réalisé avec le [/Planning%20Poker%20-%20Une%20technique%20de%20planification%20et%20d%27estimation%20agile Planning Poker (fr)]). Par exemple, prenons une équipe qui discute d'une story particulière dont l'effort est estimé entre trois et cinq points. Ses membres ont une discussion légitime sur le sujet. A certains moments de la discussion, une ou des personnes vont rappeler à l'équipe que l'on fait pression sur elle pour augmenter la vélocité. Et certaines personnes vont proposer que l'on estime la story à cinq plutôt que trois. Je souhaite être très clair, ce n'est pas un mensonge, ce n'est pas de la gonflette. L'équipe a vraiment discuté de l'estimation à trois ou cinq. Et lorsque quelqu'un a rappelé à l'équipe qu'elle était sous pression, cette personne a donc privilégié le cinq. Et donc cette story a été estimée à cinq. Maintenant, considérons une autre story à estimer peut-être une ou deux semaines plus tard. En prenant cette nouvelle story, quelqu'un l'a comparée à celle de cinq points et s'est dit "alors, cette nouvelle story est un peu plus grosse que celle de cinq ?" et l'a donc estimé à huit. Et c'est comme cela que l'inflation des estimations survient. '''Comment empêcher l'inflation des estimations ?''' J'ai trouvé que le moyen d'empêcher l'inflation des estimations de survenir était de toujours comparer l'élément à estimer avec deux (ou plus) autres éléments du backlog produit précédemment estimés. Dans mon livre [https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning Agile Estimating and Planning], j'y fais référence en appelant cela la ''triangulation'', empruntant ainsi un vieux terme nautique pour localiser un navire. Ainsi, lorsqu'une équipe réfléchit à estimer une story à cinq points, elle compare d'abord cette story à deux autres stories, idéalement une plus petite et une plus grosse. En décidant d'estimer ou non la story à cinq points, l'équipe va comparer la story à une story à trois points et se demander ''"Est-ce que l'effort pour produire cette nouvelle story est un peu plus grand que cette story à trois points ?"''. Ensuite, l'équipe va la comparer à une story de huit ou treize points. Et elle va vouloir voir si la story est convenablement taillée à cinq en la comparant à l'une de ces deux-là. Ces comparaisons sont illustrées dans le schéma suivant : [[Image:Triangulating-003.jpeg|Triangulating-003.jpeg]] ''Triangulation d'une story à 5 points en la comparant avec une story à 3 points et une story à 13 points.'' Lorsqu'un élément à estimer est comparé à deux (ou plus) éléments précédemment estimés, cela aide à garantir la cohérence des estimations. Idéalement, nous aimerions comparer chaque estimation à ''toutes'' les estimations précédentes. Mais cela représenterait trop de travail. Trianguler une story avec deux (ou plus) stories est généralement suffisant. Si nous considérons que ces stories sont les noeuds d'un graphe, on peut visualiser la triangulation en dessinant des lignes entre chacun des noeuds que l'équipe utilisera explicitement pour comparer lors de chaque estimation. C'est ce que l'on peut voir dans le schéma suivant : [[Image:Triangulating-004.jpeg|Triangulating-004.jpeg]] ''Chaque story, de A à F, a été comparée à deux ou trois autres stories.'' Ici, nous pouvons voir que les éléments A et B du backlog produit ont été comparés chacun à trois autres éléments. Les éléments de backlog C à F ont été comparés chacun deux fois. '''La triangulation arrête l'inflation des estimations''' La triangulation empêche l'inflation des estimations parce qu'en recourant à deux comparaisons on fait émerger le problème d'inflation des estimations. Pour le voir, reprenons l'équipe qui essaye de se décider sur l'estimation d'une story à trois ou cinq points. Se rappelant qu'elle est mise sous la pression d'augmenter sa vélocité, ses membres décident de l'estimer à cinq points. Et elle semble légitimement juste un petit peu plus grosse que d'autres stories à trois points. Mais, lorsque l'équipe triangule cette story avec d'autres de cinq ou huit points, elle s'apercevra probablement que la story ne fait en fait pas cinq points. '''Il existe encore un meilleur moyen d'empêcher l'inflation des estimations''' Il existe encore un meilleur moyen d'empêcher l'inflation des estimations. Mais puisque cet article est déjà trop long, je le garde pour l'astuce de la semaine que je publie par email chaque jeudi. Si vous n'êtes pas encore inscrit, je vous invite à vous [https://www.mountaingoatsoftware.com/email-tips le faire] si cela vous intéresse d'en apprendre plus. '''Qu'en pensez-vous ?''' ''Est-ce que votre équipe s'est heurtée au problème de l'inflation des estimations ? Comment avez-vous traité ce problème ? N'hésitez pas à partager vos réflexions dans les commentaires ci-dessous.''

Comment empêcher l'inflation des estimations - Historique des versions

Fabrice Aimetti le 23 avril 2020 à 17:46

Fabrice Aimetti le 23 avril 2020 à 17:46

Fabrice Aimetti le 28 août 2018 à 18:13

Fabrice Aimetti le 28 août 2018 à 18:12

Fabrice Aimetti le 1 juillet 2018 à 10:50

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation Auteur : Mike Cohn Source : [https://www.moun... »

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation
Auteur : Mike Cohn
Source : [https://www.moun... »