La somme des estimations des stories découpées n'a pas besoin d'être égale à l'estimation de la story originale
Auteur : Mike Cohn (@mikecohn)
Source : Estimates on Split Stories Do Not Need to Equal the Original
Date : 20/07/2015
Traducteur : Fabrice Aimetti
Date : 22/08/2015
Traduction :
On me demande souvent si la somme des estimations des plus petites stories doit être égale à l'estimation de la story originale plus grosse.
Non.
L'une des raisons pour lesquelles on découpe des stories, c'est de mieux les comprendre. Les membres de l'équipe discutent de la story avec le product owner. Puisque le product owner clarifie une user story, l'équipe en saura plus sur le travail qu'elle a à réaliser.
Cette meilleure connaissance doit théoriquement se refléter dans les estimations que l'équipe fournit. Si la somme de ces estimations ne donne pas la même valeur que la story originale, qu'il en soit ainsi.
Mais qu'en est-il du Burndown ?
Mais, je vous entends me poser la question, qu'en est-il du burndown chart de la version ? On a dit à un chef, client ou utilisateur qu'une story valait 20 points. Maintenant que l'équipe l'a découpée, elle devient plus grosse.
Et bien, d'abord, je me sens toujours obligé de dire ceci : nous devrions toujours insister auprès de nos chefs, clients ou utilisateurs sur le fait que les estimations sont des estimations (NdT : cf. Exactimation), et non des engagements.
Lorsque nous leur disons que la story vaut 20 points, cela signifie peut-être 20, peut-être 15, peut-être 25. Peut-être 10 ou 40 si les choses se passent particulièrement bien ou mal.
D'accord, vous avez probablement transmis ce message, et il est entré dans une oreille puis sorti de l'autre de votre chef, client ou utilisateur. Voici donc autre chose que vous pourriez faire pour vous protéger d'une story qui grossit lorsqu'elle est découpée et que ses stories liées sont ré-estimées.
J'ai toujours écrit et enseigné que les chiffres du Planning Poker devraient plutôt être envisagés comme des seaux d'eau de différentes tailles.
Par exemple, vous avez une carte 8 et une carte 13, mais pas de carte 10. Si vous avez une story pour laquelle vous pensez qu'elle vaut 10, vous devriez l'estimer à 13. Ce léger arrondi supérieur (qui se produit uniquement dans l'intervalle des grands chiffres) permettra d'atténuer l'effet des stories qui grossissent lorsqu'elles sont découpées.
Considérons l'exemple d'une story que l'équipe a estimée à 15. Si les membres de l'équipe jouent au Planning Poker de la manière que je recommande, ils estimeront cette grosse story à 20.
Plus tard, ils la découperont en de multiples plus petites stories. Disons qu'ils la découpent en stories estimées à 8, 8 et 5. Donc 21. C'est significativement plus grand que le 15 auquel ils avaient initialement pensé, mais pas si éloigné du tout du 20 qu'ils ont finalement affecté à la story.
Dans la pratique, j'ai trouvé que ce léger biais pessimiste fonctionnait bien pour contrer la tendance naturelle qu'ont les développeurs, c'est mon avis, à sous-estimer, et à offrir un bon équilibre pour ceux qui seraient excessivement choqués que les ré-estimations excèdent l'estimation initiale.
