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

La suite de Fibonacci dans l'estimation des Story

Ken Schwaber (co-fondateur de la méthode Scrum) nous préconise d'utiliser le poker planning basé sur la vraie suite de Fibonacci (http://kenschwaber.wordpress.com/2011/03/11/planning-poker). En lisant cet article publié sur son blog, vous verrez comment la communauté scientifique, en la personne du Dr Stephen Hawking l'a interpellé au sujet de l'anormale simplification qui a été opérée sur les cartes dédiées à l'exercice...

 

Je vous propose ci-dessous la traduction de l'article :

J'ai utilisé la technique d'estimation du Planning Poker de l'extreme Programming depuis que James Grenning me l'a montré en 2003. Beaucoup a été écrit à ce sujet, comment l'utiliser, et comment il conduit rapidement à des estimations d'aussi bonne qualité que toute autre technique plus détaillée et plus longue. J'aime bien quand quelque chose que j'utilise marche. Je l'aime encore plus quand je peux pointer dans la nature ou dans la science les principes fondamentaux sous-jacents expliquant leur fonctionnement. La séquence de chiffres sur lesquel le poker planning est basé provient de l'ensemble de Fibonacci: «Par définition, les deux premiers nombres de Fibonacci sont 0 et 1, et chaque numéro ultérieur est la somme des deux précédents. Certaines sources suppriment le 0 initial, au lieu de commencer la séquence avec deux 1s. En termes mathématiques, la séquence des nombres de Fibonacci Fn est définie par la relation de récurrence Fn = Fn-1 + Fn-2 avec des valeurs semences F0 et F1 = 0 = 1 Wikipedia : Cela nous ramène à des lois naturelles, tels que la taille relative entre les verticilles dans une coquille de nautile, et le nombre d'or provenant de la sommation de l'inverse de l'ensemble: {This ties back to nature, such as the relative size between the whorls in a nautilus shell, and the golden ratio derived from the summation of the inverse of the set:} où {where } Source: http://en.wikipedia.org/wiki/Fibonacci_number Alors, fidèle à la nature, je me sers de ponts entre le poker planning et les numéros 1, 2, 3, 5, 8, 13, 21, 34, 55 ..., en fonction de la taille du backlog de produit. Imaginez ma surprise quand j'ai été appelé en grande détresse par le Dr Stephen Hawking, le physicien théorique. Il était curieux de savoir qui «fricotait » avec la séquence de Fibonacci. Lui et ses compagnons avaient remarqué une recrudescence de phénomènes affligeant ces derniers temps, tels que:    1. La vitesse de la lumière commence à varier de manière imprévisible.    2. La chute d'objets à partir d'arbres à différents vitesses qui étaient indépendants de tous attributs connus.    3. Les Coquilles de Nautilus éclataient spontanément.    4. D'autres perturbations inquiétantes de l'ordre naturel. Ils avaient étudié le problème, et suivis depuis ses origines jusqu'à ce jour, la communauté des développeurs de logiciels agiles. Ils ont constaté que plusieurs d'entre nous avaient perverti la suite de Fibonacci. Ils ont trouvé un certain nombre de jeux de cartes et des affiches qui montrent la séquence suivante: Dr Hawking indiqué un haut degré de probabilité qu'il y ait une corrélation entre la variation anormale de phénomènes naturels et cette perversion de la séquence de Fibonacci. Dr Hawking plaide, et je soutiens, que nous cessions et que nous abstenions de notre utilisation abusive de la séquence de Fibonacci, et que nous revenions à la séquence réelle. Ce sera réaffirmera notre relation avec la nature et notre monde. Best, Ken Schwaber

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

Scrum Café bordelais du 14 Septembre 2011

Une 50aine de participants réunis dans un amphi de l'EPSI Bordeaux,

plusieurs Serious Games intéressants.

Pour entamer la session, Philippe Launay nous a donné des précisions sur la dernière mouture de Scrum (Juillet 2011).

Rien de révolutionnaire, mais quelques précisions intéressantes. Par exemple sur le contenu de la Backlog qui devient ordonnée et non pas priorisée. Le plan de release a également disparu...

Pour en savoir plus, je vous renvoie vers le site de Fabrice Aimetti "Agilarium.fr"

NDLR : dans le cas d'une réécriture iso-fonctionnelle, tout (ou presque) est en effet aussi important, mais il faut bien commencer quelque part.

Je retiens surtout pour l'animation des ateliers la présence d'un observateur par équipe. Lorsque c'est bien fait, l'observateur apporte beaucoup de choses sur le déroulement de l'atelier et sur l' "auto-organisation" des équipes.

La session a duré un peu en longueur, succès oblige!

Bon je reviens à la prochaine session, j'ai une bonne marge de progression...

Scrum Café n°1 - organisé chez notre client

Le 15 Septembre dernier (de 12h30 à 14h00), nous organisions notre premier Scrum Café chez notre client. Nous étions une vingtaine de personnes.

Après avoir présenté notre équipe et fait un bilan sur les formations Scrum dispensées, nous avons lancé un premier atelier sur "le premier projet Scrum".

Voici ce qui a émergé des deux groupes :

Groupe 1 : 4 objectifs ordonnés :

• Améliorer la motivation des équipes
• Auto Organisation,
• Travail en binôme,
• Moins de ressources critiques,
• Faciliter l’intégration,
• Implication du client et priorisation des besoins (client)
• Simplification du process existant et le rendre plus efficace
• Améliorer la qualité des livrables sur un périmètre restreint
• un frein à Scrum
• Contraintes opérationnelles
• un élément factuel d’amélioration apporté par Scrum
• Communication au niveau de l’équipe

Groupe 2 : 4 objectifs

• Rapprochement entre l’équipe et le client
• Facilité de communication intra équipe
• Mise en lumière rapide des problèmes
• Amélioration de la qualité

En guise de conclusion, quelques points supplémentaires :

• L’importance de la démo de fin de Sprint qui incite les développeurs a faire de réels tests fonctionnels de l’application (augmentation du nombre de tests)
• La mêlée quotidienne comme élément crucial de communication au sein de l’équipe
• La Backlog de Sprint qui permet un partage des objectifs, une vision claire de ce qu’il y a à faire.
• Création d’un vrai sentiment appartenance à l’équipe.

(...) à rapprocher des 4 valeurs de l'agilité :

1. L’équipe :
• « Les individus et leurs interactions plus que les processus et les outils »
2. L’application :
• « Des logiciels opérationnels plus qu’une documentation exhaustive »
3. La collaboration :
• « La collaboration avec les clients plus que la négociation contractuelle »
4. L'acceptation du changement :
• « L’adaptation au changement plus que le suivi d’un plan »

En fin, nous avons fait une rétrospective afin de dégager les améliorations à apporter pour la prochaine réunion le 6 Octobre prochain :

• Tout le monde n'aime pas le café : prévoir du thé vert ! (à la menthe)
• Le démarrage a été difficile : respecter le time-boxing de la session et démarrer à l'heure
• Le travail en groupe était laborieux : pour les ateliers, réduire la taille de groupes,
• La salle manquait de chaises : prévoir une salle plus grande si 20 personnes,
• Après les ateliers, il maquait une conclusion : prévoir de confronter les résultats des ateliers produits par chaque groupe,

L'humour à Gilles

Super Agile fait ce qu'il peut, mais il n'y a pas de magie!

L'amélioration continue et le radiateur d'informations

Un démarrage rapide :
Lorsque nous avons commencé à travailler en Scrum, nous nous sommes équipés du minimum vital :
Un tableau des tâches à base de paper-board et de gros scotch marron

Notre premier radiateur d'informations / tableau des tâches

Progressivement, nous avons amélioré (merci à Pierre), nous sommes passés au tableau aimanté avec post-its imprimés. La(es) Backlog(s) sous Excel ayant évolué aussi.

Radiateur d'informations :

Petit à petit on a amélioré la présentation et la fabrication des post-its

 

 Tâches et Stories en cours + BurnDown et BurnUp

Les tâches et Stories en cours + les indicateurs de base

Dernière amélioration visible : une gestion des risques agile / indice de confiance

Burndown, Burnup et indice de confiance Scrum