L'estimation par similitude d'effort

Une alternative au Planning Poker pour faire vite une première planification de release

Pour estimer les stories du backlog, le Planning Poker est une pratique désormais populaire[1].

Une séance de Planning Poker prend du temps. Pour estimer un backlog initial de 30 à 50 stories, il faut compter une demi-journée. Trop long pour être pratiqué dans une formation. Depuis 2 ans et demi et la lecture du billet Affinity Estimating de Kane Mar, je l'ai remplacé par l'estimation par similitude.

C'est comme sur les photos de classe où on met les petits devant et les grands derrière, il s'agit de trier les stories du backlog selon qu'elles demandent un petit effort, un moyen ou un plus grand.

Le point de départ pour cet atelier est d'avoir un backlog priorisé. Il se pratique après une séance d'identification des stories, avant la première planification de release. On dispose donc des stories décrites sur des post-it et rangées par priorité sur un tableau blanc.

Je procède de la façon suivante :

  • j'inscris l'ordre des stories dans un coin du post-it
  • je demande à l'équipe de venir devant le tableau
  • je demande 2 volontaires
  • j'explique l'objectif de l'atelier qui est de ranger les stories par taille de l'effort pour les réaliser
  • les 2 volontaires commencent à manipuler les stories en sélectionnant les plus petites et les mettent à une extrémité libre du tableau (la dernière fois c'était à droite)

Estimation par similitude

  • ils continuent en prenant ensuite les stories dans l'ordre du backlog et en les plaçant relativement au premier paquet de post-it : celles qui sont juste un peu plus grandes à côté, celles qui sont vraiment plus grandes un peu plus loin
  • une fois que toutes les stories sont grossièrement placées, toute l'équipe participe pour affiner le rangement, avec l'objectif de regrouper les stories par similitude d'effort
  • quand l'équipe considère être arrivée à un regroupement qui tient la route, on a donc des petits paquets de post-it placés horizontalement sur le tableau (dans ma dernière formation, c'était donc les plus petites stories à droite et les plus grandes à gauche). On obtient généralement 5 ou 6 paquets
  • j'arrive avec d'autres post-it sur lesquels on trouve les chiffres de la suite de Fibonacci (1, 2, 3, 5, 8 et 13) et je les colle au dessus des paquets
  • cela donne l'estimation pour chaque story du paquet, que j'écris dans un autre coin de son post-it
  • je remets les stories dans l'ordre initial

Cela dure environ vingt minutes, en tout, pour un backlog d'une trentaine d'éléments.

Il m'arrive aussi de recommander cette technique quand je fais du coaching, pour la première estimation du backlog. Une fois les sprints lancés, pour estimer les changements dans le backlog à chaque sprint, le Planning Poker reste préférable.

Notes

[1] ce n'était pas le cas quand j'en ai parlé la première fois dans ce blog, il y a presque 5 ans. Je ne cite même pas le terme Planning Poker dans mon billet, par peur de dérouter. Plus tard, je citais bien le Planning Poker

Commentaires

1. Le mardi 14 décembre 2010, 09:27 par Nicolas

Merci pour le tuyau !
J'ai justement eu un problème similaire, avec un backlog d'une centaine de stories, et malheureusement, je ne connaissais pas encore cette technique.

2. Le jeudi 16 décembre 2010, 09:54 par Bastien

Très bonne technique, merci.

As-tu déjà expérimenté cette technique sur un backlog ayant déjà des estimations? Je pense par exemple dans le cas où un grand nombre de nouvelle user stories venaient le compléter.

Non, mais la technique peut être appliquée en commençant par ranger les stories déjà estimées par colonnes correspondant aux points.
3. Le vendredi 17 décembre 2010, 08:18 par Arnaud

Quand c'est possible, ne serait-il pas judicieux de glisser quelques US déjà réalisées et positionner ainsi des "bouées de sauvetage"... Juste histoire de ne pas se planter sur toute la ligne !

C'est surtout intéressant la première fois quand on ne dispose d'encore rien. Sinon le risque de se planter sur toute la ligne n'existe pas, puisque l'estimation est relative.
4. Le mercredi 22 décembre 2010, 22:20 par stemlaur

Le pattern MVC est puissant, mais la plupart du temps c'est le pattern BVC qui est utilisé ^^ http://stemlaur.com/blog/2010/12/02...