Pour que les backlog grooming ne soient plus une corvée

La semaine dernière j'organisais une séance de backlog grooming avec mon équipe. Personne n'avait envie de venir. Au début du projet on ne faisait pas de grooming. Ça manquait (sprint planning trop longs, stories refusées par l'équipe. Frustration..) Tout le monde était d'accord pour le dire. Mais pour autant, personne n'avait envie de venir et de participer. J'étais persuadée que l'on pouvait le faire avec plaisir et efficacité. J'ai cherché. Je n'ai rien trouvé pour m'aider. Beaucoup d’articles portent sur l’intérêt des groomings mais pas vraiment sur le déroulé. Voilà les petites choses que j'ai testées.

INVITER TOUTE L’ÉQUIPE

J'ai invité tout le monde. Toute l'équipe : développeurs, intégrateur, product owner, ergonome, testeur. On avait testé des groomings en présence de 10% de l’équipe. Des développeurs qui reportent aux autres les fruit des discussions. Ça ne marchait pas. Il y avait interprétation et perte d'informations dans la restitution.. De nouvelles questions émergeaient. Mais le Product Owner n'était plus là pour y répondre. Certains avaient des idées. Ils ne disposaient pas d’un moment pour les formuler.

DES PETITES SÉANCES RÉPÉTÉES

J'ai volontairement réduit la durée. 1h30 plutôt que 2h. Au delà l'attention se disperse. Et je pense les réduire encore plus. Et en faire plus souvent. Que ça devienne un rendez-vous hebdomadaire. Un rituel.

CHANGER LE VOCABULAIRE

J’ai arrêté de parler de réunion mais d'atelier. Pour beaucoup réunion = passivité. Un "Atelier" se rapproche plus de travaux pratiques. Un dev me dit "à partir du moment où je passe du temps à faire autre chose que développer c'est une réunion pour moi". Bon, on verra si cette nuance de vocabulaire apportera quelque chose dans le temps.

RAPPELER L’OBJECTIF D'UN BACKLOG GROOMING

C’est important de rappeler l’objectif d’un atelier, avant de démarrer, quel qu'il soit. Ça permet d’ancrer les gens dans la séance de travail. De les impliquer.
Pourquoi on est là ? Pourquoi on arrête de coder pendant 1h30 ?
J’ai commencé par une chose qui me paraissait essentielle : la co-conception. On va prendre du temps pour réfléchir avec le Product Owner aux fonctionnalités qu’il imagine pour son produit. On va parler priorité (on lit les stories dans l'ordre du backlog) mais aussi faisabilité, interface utilisateur (d'ailleurs là aussi tout le monde donne son avis. Pas seulement l'ergonome). D'ailleurs elle n'est pas là. Chiant mais on va survivre.
On va préparer ensemble les stories. Les rédiger, les découper, pour qu’elles soient prêtes. Mais c’est quoi une story prête ?

SE METTRE D’ACCORD SUR LA DÉFINITION D’UNE STORY PRÊTE

J’ai listé avec l’équipe tout ce que l’on mettait dans la checklist de “story prête”.
C’est une story dont a discuté.
Qui contient un titre, une description, des axes d’acceptance (quelques uns. Pas forcément tous. Je rappelle que la story est un support à la discussion. Pas des spécifications exhaustives).
C’est une story que l’on a découpé jusqu’à ce qu’elle soit suffisamment petite.
Les tâches de réalisation de cette story sont entièrement réalisables par l’équipe de développement. Cela signifie que nous avons anticipé les actions d’ouverture de flux, de préparation des environnements... Qui ne sont pas réalisées par l’équipe de développement dans le contexte de notre client.

PROPOSER UN TEMPO

Ce qui agaçait tout le monde dans les groomings : les discussions sans fin sur un sujet. Le sentiment d’avoir travaillé pendant 2h sur le contenu d’une seule story tout au plus. J’ai donc proposé de time boxer nos discussions. 10 minutes par story pas plus. En utilisant un vrai timer, de préférence avec une sonnerie bien stridente. Un timer de cuisine. C’est court 10 minutes. Mais ça force les gens à ne faire que des propositions claires. Si la story n’est toujours pas prête au bout de 10 minutes, on la met de côté. Le Product Owner la retravaillera seul ou avec l’aide de l’équipe. De cette façon on arrive à discuter de 7 ou 8 stories.

DONNER UN RÔLE À CHACUN

Il y a celui qui facilite (respect de la time box, du temps de parole de chacun, etc…) Il y a le scribe. Il note le résultat des discussions sur Jira. Il y a celui qui lit la story à haute voix (c’est bête mais c’est beaucoup plus efficace que lorsque c’est le PO qui lit la story lui-même.) Et tous posent des questions bien sûr.
A chaque story on libère sa chaise pour la personne de droite. Et on s'assied sur celle de gauche.
Il y a plusieurs paper-boards pour donner la possibilité à chacun de dessiner.

TUER SON PIRE ENNEMI

Le premier qui regarde son téléphone portable a un gage…

FAIRE UN ROTI

C’est un peu comme le rappel des objectifs de l’atelier. C’est un indispensable.
Ceux qui donnent une note en dessous de 4 expliquent ce qu’ils ont moins aimé et ce qu’ils changeraient dans l'organisation de la séance. Si tout le monde n'est pas d'accord on vote.

CE QUI A CHANGÉ / CE QUI POURRAIT ÊTRE MIEUX

L’équipe me demande “quand est-ce que l’on planifie le prochain grooming ?”
Les sprint planning sont beaucoup plus courts.
Le Product Owner n’a pas de mauvaise surprise. Aucune des stories qu’il présente n’est rejetée. Parce que “pas prête”.

C’est encore moi qui planifie et facilite. J’aimerais que l’équipe s’en occupe seule. Je ne cherche surtout pas à être indispensable à ce type d'atelier. Ce sera une réussite pour moi si cela apporte à l'équipe et qu'elle devient capable de mener seule ses groomings.
J’aimerais aller plus loin encore. La prochaine fois on s’assied tous par terre. Et on voit ce que ça change.

Un collègue m’a fait remarquer récemment que les groomings de mon équipe étaient des répétitions de sprint planning. Je ne les vois pas comme cela. J'écrirai bientôt sur les sprint planning.