Les Companion Games

Quand on parle d’agilité et de Scrum, on entend souvent parler de Planning Poker. Cette technique, aussi ludique qu’efficace, vise principalement à réduire les débats autour des estimations des tâches, permettant ainsi une phase d’estimation plus courte.
Ceci dit, il est parfois difficile d’utiliser le Planning Poker lors du sprint zéro… En effet, on manque à ce moment-là de points de comparaison, voir on a encore un peu de mal à cerner les user stories par manque d’information.

Que ce soit via le Planning Game d’eXtreme Programming ou avec le Planning Poker, la base de ces méthodes reste la comparaison des user stories par leur taille, augmentant selon la complexité de la user story.
James Grenning, qui a décrit pour la première fois le Planning Poker en 2002, propose plusieurs jeux, les Companion Games, afin d’estimer au mieux les stories. Ces jeux sont au nombre de cinq:

• High-Low Story Showdown (Exposition d’Histoire)
• Deal and Slide (Distribue et Glisse)
• Planning Poker
• Developer Guts (Instinct de développeur)
• Customer Guts (Instinct de Client)

High-low Story Showdown

L’idée derrière ce jeu est de trier les user stories par difficulté, rapidement et avec le moins d’effort possible.

Comme le décrit J. Grenning, il y a cinq piles disponibles, correspondant chacun à un niveau d’effort nécessaire:

• Faible
• Moyen
• Dur
• Plus d’infos
• C’est une blague!

Le dealer tire les user stories une à une et les participants décident rapidement la pile dans laquelle devrait être la story. On insistera sur le fait de minimiser les débats, on le fera plus tard.
Une fois les stories triées, on passera au Deal and Slide.

Deal and Slide

L’objectif ici est de répartir les stories par difficulté d’exécution. Pour ce faire, on traitera les piles Faible, Moyen et Dur du High-low Story Showdown une à une. Les deux autres piles seront pour réserver au client pour qu’il les affine ultérieurement.
Pour chaque pile, on placera aléatoirement les stories sur la table. Sans échange et en silence, les développeurs déplaceront (“slide”) les stories de gauche à droite, par ordre de difficulté. On pourra ici avoir autant de colonnes que besoin est, sachant que trois est en général suffisant (Facile, Normal et Dur).
Il arrivera parfois qu’une story passe d’une colonne à l’autre sans s’arrêter, simplement parce que les développeurs ne sont pas d’accord sur la difficulté attribuée. Ce jeu se faisant dans un premier temps en silence, il n’y a pas de débat et la seule solution sera de mettre ces cartes de côté.
Une fois toutes les cartes en place, on parlera des cartes écartées. Les développeurs pourront débattre d’où les mettre si c’est possible. Sinon, c’est qu’ils manquent d’informations et donc on donnera ces cartes au client pour plus tard.
Une fois toutes les stories triées, les développeurs pourront survoler les colonnes afin de s’assurer que les stories sont bien placées.

Planning Poker

C’est le moment de revenir au Planning Poker, non pas pour estimer les tâches une à une mais cette fois pour estimer chaque colonne. Comme d’habitude avec le Planning Poker, on estimera en Story Points et non pas en unité de temps.
Cette session de Planning Poker permettra notamment de se rendre compte qu’une ou plusieurs stories sont mal placées dans le cas où elles ne correspondent pas à l’estimation globale de la colonne. On pourra bien sûr les déplacer dans une colonne plus adaptée si tout le monde est d’accord.
A la fin de cette session, on notera sur chaque user story l’estimation de sa colonne.

Developer Guts

Tout comme l’estimation des stories, l’estimation de la vélocité peut être difficile. C’est néanmoins l’objectif de ce jeu ce basant sur l’instinct (gut en anglais) des développeurs.
A ce stade, on connait déjà la durée de chaque sprint. Les développeurs vont donc choisir un groupe de stories qu’ils pensent pouvoir terminer dans la durée du sprint. Une fois qu’ils sont tous d’accord sur cet échantillon, on additionnera les points qu’on a inscrits sur les cartes au cours du jeu précédent. On obtient ainsi la première estimation de vélocité.
Pour affiner le résultat, on prendra un autre échantillon correspondant à la même vélocité et on demandera à l’équipe de confirmer qu’elle est capable de la terminer dans le même délai.
Cet exercice pouvant être difficile, il peut être intéressant de réduire cet échantillon en tâche concrètes.
On fera autant de partie que nécessaire pour que l’équipe soit confortable avec la vélocité obtenue. Notez que la vélocité évoluera au cours du projet, permettant une prédictibilité de plus en plus fiable.

Customer Guts

Comme toujours, chaque sprint a pour but d’offrir le plus de Business Value possible. Ce dernier jeu servira donc à ébaucher un plan de déploiement.
Le(s) Product Owner(s) va ici regrouper les stories par itération, sachant que le total de points ne pourra pas dépasser la vélocité obtenu pendant le Developer Guts. Pour cela, on organisera les groupes en piles allant de gauche à droite, dans l’ordre des itérations. Les stories des premières itérations devront donc pouvoir être exécutées immédiatement.
Une fois que l’équipe de développement travaillera sur les premières itérations, le PO aura le temps d’affiner les stories dans les piles Plus d’infos et C’est une blague! du High-low Story Showdown.

Fréquence

On pourra faire autant de sessions de Companion Games que nécessaire, ponctuellement au début du projet et ensuite régulièrement après quelques itérations.

Conclusion

On l’a vu, il est beaucoup plus simple d’estimer une user story lorsqu’on peut la comparer à d’autres… C’est là qu’entrent en jeu les Companion Games en nous aidant lors des premières estimations. Bien entendu, on pourra se contenter du Planning Poker une fois qu’on aura une base suffisante de stories à comparer, laissant peu à peu de côté les Companion Games.

Ces jeux nous permettront donc, dès le début du projet, d’estimer les stories et la vélocité, estimations en général difficiles de part leur nature.