Affichage des articles dont le libellé est revue de backlog. Afficher tous les articles
Affichage des articles dont le libellé est revue de backlog. Afficher tous les articles

lundi 26 mars 2012

Revue de Backlog : technique d'estimation

Magic Estimation :
(le 29/04/2012 : j'ajoute à ce billet le nom de la technique d'estimation décrite)

Traditionnellement, lors de nos revues de Backlog nous réalisions nos estimations en équipe, en appliquant la technique du Planning Poker.

Récemment, Michel Goldenberg a donné des formations spécifiques certifiantes de Product Owner et de Scrum Master chez notre client. Son public était essentiellement composé de personnes a qui j'avais moi-même dispensé une formation "généraliste" sur Scrum.

J'ai donc profité de sa présence dans les locaux pour me glisser à la fin de la session et échanger avec lui sur les pratiques et techniques qu'il préconisait.

Volontiers provocateur, Michel Goldenberg me fit remarquer que le Poker Planning n'était pas une bonne pratique! Enfin, qu'il en existait de meilleures...

En trois minutes il nous a tous convaincus, et ce matin nous avons mis en place sa préconisation :
  •    le Scrum Master  écrit la suite de Fibonacci au tableau : un nombre de la suite par ligne
  •    le Scrum Master  place aléatoirement les post-it des Stories sur le tableau
  •    l'équipe estime la position relative des User Stories en déplaçant les post-its
  •    les détails des histoires sont discutés en séance avec le Product Owner

Le premier gros avantage pour l'estimation est le coté visuel :
  •    chaque Story prend place à coté d'une autre de même taille
  •    et tant que tout le monde n'est pas d'accord sur l'estimation, on creuse les détails

Cela a plusieurs avantages : On ne se focalise pas sur le nombre de points que vaut la Story, mais plus sur le poids relatif des unes par rapport aux autres. Si la Story de base (template) est représentative et que les Stories sont correctement décrites, le travail d'estimation  en relatif est alors très rapide et efficace :
 "C'est plus grand que" ou "plus petit que" se résout facilement en équipe et favorise les échanges entre équipiers.

Autre conseil de Michel Goldenberg, pour la revue de Release Backlog :  demander à chaque membre de l'équipe de prendre des notes personnelles sur les détails des Stories. Ainsi lorsque au 5éme ou 6ème Sprint, lorsque l'on rediscutera de la Story pour une Revue de Backlog du Sprint, chacun à l'aide de ses notes pourra se remémorer les détails discutés. La pluralité des notes permettant de conserver trace des différents aspects de la Story et favorisant la résurgence des souvenirs (en 3D).

lundi 26 septembre 2011

Formation Scrum des 21 et 22 Septembre 2011

Dernière formation planifiée à ce jour :
  • 8 personnes étaient présentes,
  • 2 products owners identifiés, 
  • 1 chef de projet qui se voit bien devenir product owner
  • Les autres personnes avaient besoin de connaitre et comprendre la méthode afin de pouvoir travailler avec des équipes Scrum, des stakeholders en somme.

Pour cette formation, je me suis inspiré du Scrum Café Bordelais : j'ai introduit le rôle d'observateur dans les ateliers. 

Les règles du jeux, décliné ensuite au niveau des Users Stories


Lorsque le product owner présente son projet (vision) et cherche à identifier des features, puis des user stories il était intéressant de voir la pertinence des questions, et le niveau de compréhension des participants qui s'affine. 
Il faut rester vigilant à ce que les discussions servent l'objectif, sinon, les participants racontent volontiers leur vie. Une fois cadré, en 1/4 d'heure, le jeux produit ses effets.  On recommence ensuite avec l'identification des premières user stories à planifier dans le(s) premier(s) Sprint(s).



Le résultat : les Backlogs

Je doute qu'un cahier des charges ou autre expression de besoin puisse être aussi efficace ( rapport temps passé/compréhension). 

Il est vrai que ces documents servent surtout à fixer les responsabilités une fois que les premiers problèmes font surface...