J’avoue ne pas totalement accrocher avec le mouvement #noestimate.
Je comprends bien la volonté de gagner du temps (ou plutôt d’éviter d’en gaspiller) et je sais que l’on peut planifier des releases sans avoir besoin d’estimer chacune des User Story (@claudeaubry détaille cela précisément dans la version 4 de son livre sur Scrum – Ce qui lui a d’ailleurs valu plusieurs remarques de ma part lorsque j’en ai fait la relecture).
D’autres personnes considèrent que dès lors qu’une estimation est donnée, elle est considérée comme un engagement et que tout engagement amène du mauvais stress sur l’équipe (la pression) et un biais potentiel sur la qualité de ce qui sera produit (afin de tenir l’engagement). Et donc qu’il est préférable de ne pas donner d’estimation pour éviter ces désagréments.
De la même façon, j’ai lu et entendu que puisque les managers ne comprennent pas l’utilisation des indicateurs agiles et qu’il est trop difficile de leur en expliquer le fonctionnement (ou peut être simplement qu’ils ne veulent pas entendre) alors le plus simple est d’arrêter de les produire. Donc plutôt que de s’occuper du problème réel, on fait disparaitre la conséquence en espérant que cela ira mieux … un doux rêve 🙂
De mon coté, je trouve que passer du temps à faire des estimations a de la valeur pour peu que l’on tienne compte des éléments suivants :
Chaque estimation est fausse
C’est un de mes leitmotiv lorsque j’accompagne des équipes agiles, je dis et je répète que chaque estimation unitaire de story est fausse et que ce ne peut donc pas être une référence unitaire sur laquelle baser un quelconque engagement.
Et comme elle est fausse, il ne faut pas y passer plus de temps que nécessaire, c’est à dire ne pas passer 10 minutes à discuter si c’est 1 points ou plutôt 2 points … cela ne changera rien à la planification finale.
Chaque estimation est en points (sans unité)
Et donc surtout pas de jours ou d’heures, ces unités pourront éventuellement être utilisées plus tard lors de la planification du sprint.
Chez un de mes clients, les équipes parlent de « points patate » … j’aime bien ce concept 🙂
Chaque estimation est une estimation d’équipe
Faire bien attention a ne pas estimer sa capacité personnelle à réaliser une story et bien raisonner au niveau de l’équipe … ce qui n’est pas toujours simple pour des équipiers à qui on a demandé durant de nombreuses années des estimations individuelles du genre : « De combien de temps as-tu besoin pour faire cette tâche ? »
Et parfois même, après la réponse « 5 jours » arrivait « bon, je t’en donne 2 » … du vécu 🙂
L’agilité repose sur l’intelligence collective de l’équipe et je considère que les meetings d’affinage du Backlog avec l’estimation des Story en points est la représentation la plus intéressante de ce concept.
Chaque estimation est relative
Pour aider les équipiers à bien estimer au niveau de l’équipe, la meilleure technique consiste à estimer relativement les choses les unes par rapport aux autres.
Pour ce faire, je recommande souvent aux Scrum Master des équipes que j’accompagne de maintenir un tableau, visuel de préférence (une feuille de paperboard convient parfaitement), pour y référencer quelques Story qui ont été estimées précédemment et que les équipiers vont utiliser comme référentiel commun.
Un schéma théorique au début de cet article illustre cette pratique.
Cette feuille est apportée et affichée à chaque réunion d’affinage Backlog pour aider les équipiers à se rappeler du référentiel qu’ils utilisent (et cela réduit bien souvent significativement la durée des affinages).
Le Scrum Master est en charge de remplacer régulièrement des Story anciennes par des Story plus récentes dont les équipiers connaissent mieux le contenu.
Chaque estimation est honnête
Surtout ne pas chiffrer le pire cas, c’est à dire celui où tous les risques identifiés vont être avérés, et rester dans une logique d’estimation relative … même si vous ne savez pas exactement ce qu’il y a à faire … et c’est cela qui est difficile.
Chaque estimation est indépendante de la charge de réalisation
L’équipe ne sait pas encore dans quel itération la Story sera réalisée, qui sera présent dans cette itération, quelles autres Story seront embarquées, quelles seront les actions d’amélioration en cours …
Par exemple si l’équipe à décidé aux rétrospectives précédentes de généraliser la programmation en binôme et de développer les compétences de l’équipe sur un domaine technique précis, et que cette Story couvre ce domaine technique, elle va investir du temps supplémentaire sur la réalisation de cette Story dans l’itération en cours, pour un bénéfice (retour sur investissement) qui se verra plus tard sur le projet (meilleures qualité et pluridisciplinarité).
Chaque estimation contribue à la discussion
Une des équipes que j’accompagne a un jour décidé d’arrêter les estimations, après 6 mois de pratique, c’était leur choix et je n’y ai pas vu d’inconvénient. Lors de l’affinage Backlog suivant, j’ai perçu un changement dans le comportement des équipiers vis à vis du Product Owner. Alors que 7 ou 8 Story avaient été discutées, j’ai demandé à l’équipe de « me faire plaisir » en faisant une estimation de 2 Story déjà discutées. Et avant de retourner les cartes de Poker Planning, 2 équipiers ont alors posé des questions complémentaires au PO sur ces Story. Le fait de devoir choisir une carte avec un chiffre était une action engageante pour eux, et il ne voulait pas le faire à la légère.
Bien entendu, cet exemple est spécifique à cette équipe et la votre se comporte surement différemment lors de sa pratique du #noestimate.
Je ne peux que vous conseiller de rester vigilant sur la qualité de la discussion entre les équipiers et le Product Owner lors de l’affinage Backlog et de mon coté, je vais continuer à faire la promotion de l’estimation des Story pour être bien certain que cette discussion est de qualité.
La moyenne de la vélocité est un indicateur fiable
En additionnant les points des Story finies à chaque itération, l’équipe dispose d’une mesure de vitesse appelé « vélocité », dont la valeur instantanée est fausse (comme pour les estimations). C’est à dire que ce n’est pas parce que l’équipe à fait 20 points à cette itération qu’elle en fera 20 à la suivante.
Par contre ce que je constate régulièrement, c’est que la moyenne des vélocités des itérations passées est un indicateur fiable qui permet de se projeter dans le futur avec une bonne précision (sauf si la variabilité des mesures – écart type – est trop importante). Si la moyenne des vélocités est de 20 point et qu’il reste 90 points dans le backlog de la release, il faudra bien 5 itérations pour finir cette release.
De mon point de vue c’est l’information la plus importante que l’on attend d’un indicateur de ce type : « Lever les incertitudes sur le futur du projet »
Merci Alex pour ce très bon article sur les estimations, et les pratiques de bases qui vont avec.
Moi non plus je n’adhère pas du tout au #NoEstimate, et je constate souvent que des équipes en arrivent là parce qu’elles n’arrivent pas bien à gérer leurs estimations, et c’est souvent parce qu’elles se sont écartés des fondamentaux… :-/
A part certaines situations particulières, il me semble que ces phases d’estimations collectives sont vraiment indispensables, au moins comme tu le rappelles, pour amener les échanges entre le Product Owner et les équipiers pour une bonne compréhension des fonctionnalités à réaliser… la base pour une bonne production… ça semble tellement évident, et si souvent mal mené…
Et pour finir sur les pratiques, j’ai vu d’excellents résultats, en créant des cartes (ou post-its) pour chaque story, le tout posé sur une grande table, où chacun peut déplacer vers la gauche ou la droite chaque carte, par rapport aux autres, selon ses estimations. Le côté « estimations relatives » est alors intuitif, et les échanges très riches 🙂
Merci Alex pour cet excellent article,
J’adhère en tout point et me permet d’en rajouter sur le dernier point car son effet est magique : des populations différentes (dev -pi -métier-marketing etc)se mettent à échanger sur une notion commune, mécaniquement chacun avance sur le terrain de l’autre..et le fait de « voter » engendre la discussion.
Au delà de thème de fond, cet article devrait être LE guide de survie de l’estimation devant être relu avant les pokers plannings … Arrêtons de faire cohabiter les termes « points » et « cher »…Histoire de recadrer sans débordement 😉
Salut Alex,
J’aime beaucoup ton test où face à une demande d’estimation, les équipiers posent des questions supplémentaires … C’est bien là tout l’intérêt des séances de Planning Poker : la discussion, les échanges entre équipiers et PO sont beaucoup plus importants que le chiffre à la fin … Même constat que toi également sur la fiabilité de la vélocité moyennée sur x sprints : très utile et rassurant pour les clients.
Bonjour Alex
Tout à fait en phase avec toi.
Avec les équipes (ou leur manager) qui ne savent pas faire l’abstraction du J/H et de ses décomposition (1/4j, H) je propose d’utiliser les tailles de t-shirt…
J’aime bien aussi que les équipes bâtissent leur propre échelle dans mon ego-systeme j’ai ainsi des races de chiens (du chiwawa ou dog allemand) ou mon préféré les tailles de bouteille (mais ca c’est pour une boîte dont le siège est à Nuit St George).
Une pratique que j’aime bien proposer aussi c’est la constitution d’une « carte d´iteration » (type carte de parcours de golf) pour mesurer la cohérence entre les estimations et la réalité (c’était un par 4 ca ?
Quant à la vélocité ma pratique est de la diviser par le nombre de jour consommés dans le sprint afin d’avoir un ratio du type NbPoint/JourHomme plus pratique à utiliser pour le suivi tendanciel itération après itération ou pour prévoir les prochaines itérations meme di la capacité de l’équipe change (dans des limites raisonnables)
Salut Alex, merci pour cet article !
Je regarde « de loin » le mouvement #NoEstimate, avec l’envie d’essayer pour me faire ma propre idée mais j’avoue ne jamais avoir franchi le pas 🙂
J’ai beaucoup aimé ton anecdote sur les 2 équipiers qui, en devant fournir une estimation, ont posé de nouvelles questions pour mieux comprendre la story.
« Le fait de devoir choisir une carte avec un chiffre était une action engageante pour eux, et il ne voulait pas le faire à la légère. »
Le plus important dans toute cette histoire, c’est de bien comprendre le besoin et d’avoir une compréhension commune de la fonctionnalité à implémenter.
Le but est donc la discussion, et l’estimation est un moyen (parmi d’autres ?) d’y arriver. Je ne connais pas ton contexte mais il ne faut pas non plus que l’estimation tétanise les coéquipiers parce que « une fois qu’on s’est engagé sur une estimation, c’est signé avec notre sang ».
Enfin, tu expliques tout ça très bien dans ton article 🙂
Je serais juste curieux de savoir quels moyens ou techniques les #NoEstimates mettent en œuvre pour générer de la discussion et arriver à cette compréhension partagée de la fonctionnalité.
@Marc,
Je peux parler pour mon équipe.
La discussion est essentielle, nous sommes tous bien d’accord là dessus.
Un moyen pour la générer, c’est notre définition de « prêt » pour un élément de backlog qui dit que l’équipe a fait son maximum pour le découper en éléments aussi petits que possible (sans tomber dans le piège de la « story technique » : chaque élément doit avoir une valeur business).
L’objectif de la discussion, c’est donc le découpage, pas le fait de mettre un nombre sur un élément, ni même de le comparer aux autres éléments.
Le découpage a une vraie valeur car il permet au PO de bien mieux trier ce qui mérite d’être priorisé. L’estimation chiffrée, c’est juste du temps supplémentaire perdu inutilement car il existe d’autres méthodes de prévision – entre autres celles dont je parlerai à Agile Grenoble dans la session « Ça prendra combien de temps » 🙂
Moi j’aime bien utiliser les tailles de verre pour la bière (Galopin, Demi, Pinte … )