Ecrire de bonnes US en 5 minutes

Lors du Scrum Wine 15#2 de ce soir voici le support de ma présentation : "Ecrire de bonnes US-  en 5 minutes" 

Ecrire de bonnes user stories - en 5 minutes - scrum wine v1.0 from Olivier Patou

Scrum Wine du 25 Septembre 2012

La session a été animée par Fabrice Aimetti et Alexis Monville au Cesi de Blanquefort.

La présentation de Scrum en 5minutes par Alexis était excellente :

• un flot bien maîtrisé,
• aller à l'essentiel 
• laisser le temps pour des questions

J'ai ensuite joué au Légo4Scrum. Nous étions deux équipes de 7 "agilistes" pour réaliser la ville idéale d'Alexis ( maître du jeu et Product Owner).  une très bonne simulation de la mise en oeuvre de Scrum sur un projet qui illustre différentes problématiques : 

• estimation
• priorisation
• compréhension du besoin
• critères d'acceptation
• Scrum de Scrum avec deux équipes
• les itérations (on en a fait 3)
• la rétrospective

et j'en oublie certainement....

Merci aux organisateurs et au Cesi pour l'accueil.

J'ai pris deux photos postées sur Meetup.

Scrum Cafe #6 - Le jeu des Post-its

Scrum Café #6

Lors du 6éme Scrum Café, nous avons organisé un atelier pour établir la Backlog d'un groupe de travail sur les Tests.
L'atelier a été très intéressant et on aurait tous aimé avoir plus de temps pour travailler les User Stories, mais nous n'avons qu'une heure à accorder à l'exercice.
Ce jeu permet d'établir les User Stories et de leur attribuer une valeur métier.

Voici les règles :



Le résultat obtenu n'est pas esthétique, mais de vrais sujets ont émergé et c'était le but!

Les observateurs ont remarqué que :

• La rédaction des Users Stoies : Le groupe était silencieux, et le travail studieux
• Le travail en binôme : beaucoup de discussion sur la compréhension des user stories. Les post-its n'étaient pas forcément bien rédigés et le "Afin de" était plutôt flou. Est-ce une User Story ou pas?
• Lorsque le débrief est arrivé, les user stories déja discutées on été rediscutées, et expliquées par celui qui les avait écrites. Il y avait une différence forte entre ce qui était compris et ce qui était souhaité
• Tout le monde à bien joué le jeu

Une fois les post-its regroupés on additionne les points des histoires  identiques. Ce sont généralement 

• les mieux exprimées,
• les utiles au projet
• car elles sont vite comprises et leur intérêt ne fait pas de doute

Si ce n'est pas le cas, la négociation est longue, l'histoire est peu partagée, et n'aura probablement pas les meilleures notes.

Cet exercice est utile lorsque

• l'on veut initialiser ou améliorer une Backlog Produit
• Définir une valeur métier pour des fonctionnalités
• Afin de palier à un rôle Product Owner qui serait partagé au sein d'un groupe utilisateur ou MOA.

Ce jeu peut-être réalisé avec quelques personnes de l'équipe technique afin de bénéficier également de leur créativité, et afin de leur faire partager la vision du produit.

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).

Gestion des risques sur les User Stories

Le Niko-Niko sert à mesurer l'humeur de l'équipe après chaque journée de travail. En principe des pastilles de couleur sont placées sur le radiateur d'informations (tableau des tâches) de l'équipe.
Chacun exprime anonymement s'il a passé une journée agréable, difficile ou exécrable. Je me suis inspiré de cette technique pour proposer une amélioration au cours du dernier Sprint (qui fini mardi) :
Contexte :
Lors de la rétrospective de notre dernier Sprint, l'un des équipiers à demandé à ce que nous enrichissions notre backlog d'un champ supplémentaire afin d'identifier les risques pour chaque User Story.
J'ai alors fait remarqué que nos User Stories n'étaient déjà pas assez correctement décrites, et les critères d'acceptation plutôt vagues (plutôt exprimés en terme de format de document que contenu), et que nos réunions de lancement de Sprint avaient de plus en plus tendance à s'allonger (depuis l'arrivée de deux nouveaux équipiers et le départ d'un autre).
J'ai alors proposé de s'inspirer du Niko-Niko afin que chacun s'exprime avant ou après la mêlée quotienne en posant une pastille de couleur sur les Stories pour lesquelles il perçoit un risque.
En faisant cela nous avons un double indicateur :

• de confiance sur le Sprint, valorisé en points Story
  
  • ->un graphe est produit à coté du BrunUp et du BurnDown
  

• de confiance sur chaque Story, qui porte le poids de chaque vote individuel
  
  • -> un graphe est produit pour chaque Story indiquant le nombre de vote

  

Dès le premier jour, l'équipe s'est approprié l'outil, et un rapide débrief avec le Product Owner ou les équipiers (en son absence) après la mêlée nous a permis de prendre des mesures afin de réduire le risque. Au cours du Sprint (le 25ème), nous avons placé plusieurs pastilles sur une Story (pas encore ouverte), ce qui a motivé le PO - convaincu - à la retirer sans avoir a argumenter plus.
Pour l'instant on trouve l'indicateur

• facile à utiliser,
• déclencheur d'échanges que nous n'avions avant,
• déclencheur de décisions importantes pour la tenue des objectifs des Sprints

Pour plus de détails sur la technique du Niko-Niko, je vous invite à consulter les sites suivants :

http://emmanuelchenu.blogspot.com/2009/02/niko-niko.html.

http://www.cascrum.dibus.org/2011/03/29/projet-marguerite-le-niko-niko/