Estimation d'une story en points vs en jours : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
 
Ligne 11 : Ligne 11 :
 
Traduction :<br />
 
Traduction :<br />
 
<br />
 
<br />
<span style="display: block; text-align: justify">Je souhaiterais partager quelques-unes de mes réflexions concernant l'estimation d'une story en points.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Je suis product owner de deux équipes scrum. Une équipe estime le backlog produit en points de story, l'autre utilise les jours. Lors de la planification de sprint (deux semaines de sprint), l'équipe découpe les user stories en tâches et les estime en heures.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">En comparant les deux équipes, j'ai constaté que l'estimation du backlog en points de story est beaucoup plus facile pour l'équipe. Cela a pris un certain temps pour s'y habituer mais aujourd'hui l'estimation est très simple avec une précision suffisante pour planifier une version.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">C'est plus facile parce que nous estimons la "grosseur" d'une user story, et non le temps qu'elle va prendre pour être réalisée.</span><span style="display: block; text-align: justify">[[Image:Scrum_Days_vs_StoryPoints_fr.png|Scrum_Days_vs_StoryPoints_fr.png]]<br /> </span><span style="display: block; text-align: justify">Lors d'une formation avec Mike Cohn, ce dernier a trouvé une belle manière de décrire la différence entre les jours et les points de story :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Soit deux personnes différentes, l'une est très sportive l'autre est normale. Ensuite, vous demandez aux deux personnes combien cela prendra de temps de courir jusqu'à une maison qui n'est pas très loin. La personne très sportive répond 5 minutes, l'autre répond 10 minutes. Elles pourront très difficilement se mettre d'accord sur l'estimation.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Par contre, si vous leur demandez à quelle distance se trouve la maison, vous aurez probablement deux réponses qui sont assez proches l'une de l'autre, par exemple 1000 mètres et 1200 mètres. Ils arriveront probablement à se mettre d'accord.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">C'est exactement la même situation pour les développeurs si vous leur demandez combien de temps prendra une story pour être réalisée. L'équipe donnera différentes estimations basées sur leurs niveaux d'expériences respectives. Par contre, si vous leur demandez d'estimer la "grosseur" d'une user story, ce sera plus facile pour l'équipe de l'estimer. Il y aura beaucoup moins de discussion et le processus entier prendra beaucoup moins de temps. Après quelques sessions d'estimation, chaque personne de l'équipe aura une bonne idée de ce que "grosseur" signifie.</span>
+
<span style="display: block; text-align: justify">Je souhaiterais partager quelques-unes de mes réflexions concernant l'estimation d'une story en points.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Je suis product owner de deux équipes scrum. Une équipe estime le backlog produit en points de story, l'autre utilise les jours. Lors de la planification de sprint (deux semaines de sprint), l'équipe découpe les user stories en tâches et les estime en heures.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">En comparant les deux équipes, j'ai constaté que l'estimation du backlog en points de story est beaucoup plus facile pour l'équipe. Cela a pris un certain temps pour s'y habituer mais aujourd'hui l'estimation est très simple avec une précision suffisante pour planifier une version.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">C'est plus facile parce que nous estimons la "grosseur" d'une user story, et non le temps qu'elle va prendre pour être réalisée.</span><span style="display: block; text-align: justify">[[Image:Scrum_Days_vs_StoryPoints_fr.png|Scrum_Days_vs_StoryPoints_fr.png|link=]]<br /> </span><span style="display: block; text-align: justify">Lors d'une formation avec Mike Cohn, ce dernier a trouvé une belle manière de décrire la différence entre les jours et les points de story :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Soit deux personnes différentes, l'une est très sportive l'autre est normale. Ensuite, vous demandez aux deux personnes combien cela prendra de temps de courir jusqu'à une maison qui n'est pas très loin. La personne très sportive répond 5 minutes, l'autre répond 10 minutes. Elles pourront très difficilement se mettre d'accord sur l'estimation.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Par contre, si vous leur demandez à quelle distance se trouve la maison, vous aurez probablement deux réponses qui sont assez proches l'une de l'autre, par exemple 1000 mètres et 1200 mètres. Ils arriveront probablement à se mettre d'accord.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">C'est exactement la même situation pour les développeurs si vous leur demandez combien de temps prendra une story pour être réalisée. L'équipe donnera différentes estimations basées sur leurs niveaux d'expériences respectives. Par contre, si vous leur demandez d'estimer la "grosseur" d'une user story, ce sera plus facile pour l'équipe de l'estimer. Il y aura beaucoup moins de discussion et le processus entier prendra beaucoup moins de temps. Après quelques sessions d'estimation, chaque personne de l'équipe aura une bonne idée de ce que "grosseur" signifie.</span>

Version actuelle datée du 31 mai 2020 à 17:43

Auteur : Olaf Grumptmann
Source : Days vs. Story Point Estimation
Date : 01/06/2014


Traducteur : Fabrice Aimetti
Date : 11/11/2015
Merci à : #Agile - Dealing with Story Points — mario lucero (@metlucero) 11 Novembre 2015
Relecteur : Nicolas Mereaux


Traduction :

Je souhaiterais partager quelques-unes de mes réflexions concernant l'estimation d'une story en points.
Je suis product owner de deux équipes scrum. Une équipe estime le backlog produit en points de story, l'autre utilise les jours. Lors de la planification de sprint (deux semaines de sprint), l'équipe découpe les user stories en tâches et les estime en heures.
En comparant les deux équipes, j'ai constaté que l'estimation du backlog en points de story est beaucoup plus facile pour l'équipe. Cela a pris un certain temps pour s'y habituer mais aujourd'hui l'estimation est très simple avec une précision suffisante pour planifier une version.
C'est plus facile parce que nous estimons la "grosseur" d'une user story, et non le temps qu'elle va prendre pour être réalisée.Scrum_Days_vs_StoryPoints_fr.png
Lors d'une formation avec Mike Cohn, ce dernier a trouvé une belle manière de décrire la différence entre les jours et les points de story :
Soit deux personnes différentes, l'une est très sportive l'autre est normale. Ensuite, vous demandez aux deux personnes combien cela prendra de temps de courir jusqu'à une maison qui n'est pas très loin. La personne très sportive répond 5 minutes, l'autre répond 10 minutes. Elles pourront très difficilement se mettre d'accord sur l'estimation.
Par contre, si vous leur demandez à quelle distance se trouve la maison, vous aurez probablement deux réponses qui sont assez proches l'une de l'autre, par exemple 1000 mètres et 1200 mètres. Ils arriveront probablement à se mettre d'accord.
C'est exactement la même situation pour les développeurs si vous leur demandez combien de temps prendra une story pour être réalisée. L'équipe donnera différentes estimations basées sur leurs niveaux d'expériences respectives. Par contre, si vous leur demandez d'estimer la "grosseur" d'une user story, ce sera plus facile pour l'équipe de l'estimer. Il y aura beaucoup moins de discussion et le processus entier prendra beaucoup moins de temps. Après quelques sessions d'estimation, chaque personne de l'équipe aura une bonne idée de ce que "grosseur" signifie.