Comment réussir un backlog grooming ?

Le backlog grooming (ou simplement grooming), c’est la cérémonie durant laquelle on présente à son équipe les nouveaux récits utilisateurs.

L’idée première d’un backlog grooming est de pouvoir valider la faisabilité technique et établir une estimation de réalisation des user stories.

Oui mais… 
En réalité le backlog grooming c’est beaucoup plus que ca !

Dans cette article je vous explique:

• Pourquoi le backlog grooming est la réunion la plus importante de votre job ?
• Comment éviter que cette cérémonie se transforme en cauchemar ?
• Quels sont les codes pour réussir son backlog grooming à tous les coups ?

Le mythe d’un backlog grooming réussi

En théorie, le backlog grooming doit vous permettre de pouvoir d’estimer l’effort de chacune de vos users stories afin d’établir un planning de développement.

Le backlog grooming demande la présence de toute l’équipe car chaque membre doit être en mesure de comprendre le détails des récits utilisateurs.

Sans la présence de toutes les forces, il est impossible d’estimer la charge de travail correctement.

Ne fixez pas un objectif au backlog grooming :

Là je pense que certains font faire des bonds.  Comment ? Pas d’objectifs mais c’est tout le contraire. Le backlog grooming doit permettre de produire un résultat sinon il est raté.

A priori oui, cette cérémonie doit être la conclusion de votre travail de concepteur.

Au terme d’une la réunion, vous devez avoir “groomé” le plus de users stories possibles présentés à votre équipe.

Même si je partage cette vision idéale, quand j’entame cette cérémonie, je n’ai aucun objectif sur la quantité de récits utilisateurs à estimer.

La raison est simple : Le backlog grooming est avant tout un échange entre vous et votre équipe.  Voyez là comme une simple discussion, voir un brainstorming, rien de plus.

Pourquoi vous ne devriez pas vous imposer d’objectifs.

Exemple :

• Prenons le cas que vous commencez une cérémonie de grooming de 60 minutes avec votre équipe au complet.
• Vous avez rédigé 5 users stories qui doivent impérativement être implémentées pour le prochain sprint.
• Votre objectif à la fin du grooming est d’avoir l’estimation de ces 5 users stories, point final.

Dans cet exemple, votre principal ennemi est le temps.

• 60 minutes pour 5 users stories. Ca fait 12 minutes par user story. Arrondissons à 10 minutes (un meeting ne commence jamais à l’heure).
• En 10 minutes, vous allez devoir présenter votre story, répondre à toutes les questions et l’estimer à l’unanimité.
• Honnêtement, sauf si vous rédigez comme un boss ou que vos user story sont hyper simples à implémenter, c’est mission impossible !
• La réalité c’est que certaines user story sont parfois difficiles à comprendre pour vos développeurs.
• Malgré toute l’attention que vous avez mis à les rédiger, vous avez oublié des détails.
• Parfois il manque une interaction dans le prototype ou le design en pièce jointe.
• Peu importe la situation, vous savez qu’au moment où vous présentez vos user stories, vous allez devoir répondre à des questions.  Chaque membre de votre équipe va soulever un point précis qui n’a pas été spécifié.
  

Que faites-vous alors dans le cas où vous sentez que votre user story n’est pas prête ?

Que faites-vous si un point à besoin d’être retravaillé ?

Dans la situation où votre objectif est d’estimer coûte que coûte, vous allez devoir passer au forceps.
Résultat, vous allez obtenir vos estimations mais vous allez frustrer votre équipe. La séance va se dérouler dans le stress. 
Et cerise sur le gâteau, le jour où vos développeurs vont démarrer la tâche, ils auront des doutes sur l’implémentation.
Vous pouvez toujours rattraper le tir en clarifiant des détails plus tard mais vous venez de saboter votre séance de grooming.
A ce jeu, votre équipe va détester la séance de backlog grooming et risque de vous pourrir pour les prochaines cérémonies.

OK, mais c’est quoi le but d’un backlog grooming alors ? 

Le seul objectif d’un backlog grooming réussi est de faire comprendre vos users stories à votre équipe. Ils faut avant tout que votre équipe valide vos user stories. Pas qu’ils les estiment.

Que vous ayez 1 ou 20 user stories en réserve à estimer peu importe.  Ne vous focalisez pas sur la quantité mais le bien être de votre équipe.

Oui, vous avez bien entendu, j’insiste sur ce point “le bien être de votre équipe”.

En tant que product owner, vous êtes responsable d’une équipe, et votre principale mission est que votre équipe vous suivre où que vous alliez.
Le Product owner est le CEO du produit, et tel un CEO, il doit faire adhérer des gens à sa vision.

Un projet c’est une course de sprint, on doit arriver le plus vite possible à la ligne d’arrivée.  L’objectif est fixé avant de démarrer.

Un produit, c’est un marathon, quand on démarre on ne voit pas de ligne d’arrivée. Vous allez y consacrer beaucoup de temps, votre vision va changer sans cesse.

Au cours de ce périple, vous allez devoir être épaulé pour réussir à passer ces étapes.
Ces étapes ce sont vos sprints de 2 ou 3 semaines. Les gens qui vont vous épauler ce sont les membres de votre équipe.
Le backlog grooming c’est comme une séance d’entraînement. C’est là que vous devez répétez le travail à faire, que vous donnez les consignes.
Si les gens ne comprennent pas vos consignes ou pire ne sont pas d’accord avec, vous allez foiré votre prochain sprint.
Si vous foirez votre prochain sprint, vous allez commencer à faire douter les gens. Votre vision produit va tout doucement être remise en cause.
Si vous traversez cette étape, vous êtes mal embarqué et il y a des chances que le problème vienne de séances de backlog grooming baclés.

Le grooming, c’est le moment où l’équipe évalue le product owner.

Ne croyez pas que c’est la rétrospective. A cette étape, on parle des erreurs déjà commises.
Le grooming c’est le moment de briller. C’est le moment de partager votre vision et de faire adhérer votre équipe.

Ne vous sabotez pas. Ne soyez pas égoiste en pensant à vos objectifs de petit manager.

Pensez à montrez votre travail, votre réflexion et impliquez chaque membre à participer à la rédaction d’une vos user stories.

La réalité d’un backlog grooming réussi

La première chose à faire est d’arrêter de penser le backlog grooming comme la conclusion de vos user stories.

Oui, je sais, certaines de vos stories ont pris du temps à être rédigées. Vous avez longuement réfléchi sur la logique de la fonctionnalité. Beaucoup brainstormé avec l’équipe UX. Imaginé tous les scénarios utilisateurs.  Documentés tous les détails…
En bref vous êtes sûr de votre coup.

Simplement, retenez l’adage “tout seul on va plus vite ensemble on va plus loin”.

En clair, vous êtes peut-être le product owner, mais c’est une erreur de croire que vous seul définissez les user stories.  C’est un travail collectif.

Déroulement d’une cérémonie

En rentrant dans la salle de réunion, commencez avec cette introduction.

“Aujourd’hui, je vais vous présenter une fonctionnalité sur laquelle j’ai beaucoup travaillé ces derniers jours / semaines.

Laissez-moi 2 minutes pour vous présenter le contexte (pourquoi l’utilisateur en a besoin). Ensuite je vous décris la solution envisagée et l’impact estimé sur nos KPIs.”

Captivez votre audience. Ce n’est pas parce que vous voyez vos collègues tous les jours que vous ne devez pas les surprendre. 

Soyez capable de raconter avec ferveur vos user stories. Aller au-delà de la description écrite.

Ne faites pas l’erreur de lire mot pour mot ce que vous avez écrit.

Une fois la description de la user story terminé, dites:

“Avant de prendre vos questions techniques. J’aimerais savoir ce que vous en pensez ? “

Avez-vous compris l’objectif de cette fonctionnalité ? Pensez-vous que l’impact espéré peut être atteint”

TRÈS IMPORTANT: Ne faites pas intervenir les membres de votre équipe comme de simples consultants techniques.  Ils travaillent tous les jours sur le produit, ce sont eux qu’ils le font.  Ils n’ont peut être pas toutes la vision 360 que vous avez sur le marché, les clients etc…  mais leurs avis comptent énormément. Impliquez-les. Entamez une discussion avec eux. 

Répondez à leurs questions, donnez-leur des détails qu’ils ne connaissent pas. Partagez votre vision produit (même si c’est pour la 1000ème fois).

Écoutez et récoltez leurs avis et incitez-les à vous donner des recommandations. 

La règle est claire: Ne démarrez pas les estimations avant qu’ils aient adhérez à la fonctionnalité.

OK, mais imaginons qu’ils n’adhèrent pas !

C’est possible. Peut-être même qu’ils vont détester. Tout dépend évidemment des profils de votre équipe (J’y reviendrai plus tard dans un post dédié).

Honnêtement, à part si vous êtes vraiment à côté de la plaque, les chances sont maigres que vos développeurs rejettent à l’unanimité votre user story.  Si c’est le cas d’ailleurs, c’est plutôt une bonne nouvelle, car ils vont certainement vous éviter de faire une grosse bêtise. Pour rejeter quelque chose en masse, il faut avoir des arguments valides.

En règle générale, si il y a des commentaires négatifs, cela implique de petits ajustements. Encore une fois, brainstormez avec eux et demandez leur de proposer une solution.

Ce sont des développeurs, ingénieurs… trouvez une solution à un problème c’est ce qu’ils savent faire le mieux.

Avant tout, observez l’émulation dans la salle.  Si vous avez bien fait votre job, vous sentirez votre équipe impliquée dans la fonctionnalité. Certaines conversations peuvent même devenir passionné.

A vous de cadrer la conversation et de recentrer le débat sur la validation de la user story. Restez pro et ferme.

Ils n’adhèrent pas et maintenant ?

Une fois que tout le monde à l’air d’adhérer. Il y a deux possibilités.

Soit la user story est prête à être estimer. 

Soit, les ajustements apportés demandent un travail supplémentaire au niveau de la description des critères d’acceptation. 

Dans le cas 1, demandez à vos collaborateurs s’ils ont des questions sur la faisabilité etc… et démarrez l’estimation.  Je ne détaille pas ici, vous connaissez votre job.

Dans le cas 2, il faut revoir votre copie. Indiquez aux membres de votre équipe

“Très bien, j’ai bien noté tous vos commentaires.
Merci beaucoup pour votre aide. Avec ça, je pense que l’on tient la killer feature.
Laissez-moi un peu le temps pour mettre tout ça au propre. Je reviens vers vous avec les modifications au prochain grooming et on estimera ça ensemble”.

Oui, vous avez bien lu. Vous reportez le grooming d’une user story à plus tard.  Ça ne veut pas dire que vous interrompez la séance.  Vous pouvez passer à une autre User story maintenant.

Certains trouveront que cette méthode est contre-productif. Au contraire elle est bien plus efficace que de passer au forceps.

Sur le court-terme vous vous assurez que les tâches de votre sprint sont bien comprises.

Sur le long-terme, vous renforcer la cohésion dans votre équipe.  En impliquant les développeurs à la construction du produit, vous créez de la confiance et gonflez la motivation de chacun.

Plus important encore, vous avancez ensemble.

C’est bien gentil mais j’ai des objectifs à tenir moi.

Oui, évidemment je vous vois venir. Il est jeudi, vous venez de finaliser toutes vos user stories. Vous planifiez une séance de grooming pour le lendemain matin en espérant que toutes les stories seront validées pour le sprint de lundi.

Honnêtement, dans ce genre de situation, vous êtes le coupable. N’incriminez personne d’autre.

En imaginant le backlog grooming comme la conclusion de vos user stories, vous avez tardé pour communiquer avec votre équipe.

Essayez d’amener des user stories en préparation plus souvent lors de vos séances de grooming. 

Allouez 20 minutes en fin de séance pour en débattre afin d’introduire vos prochaines stories et identifier les points de blocage avec vos collègues.

En adoptant cette méthode, vous aurez toujours des stories faciles à estimer lors de vos prochaines séances.

Lors de chaque séance, essayez également d’alterner des users story simples et des user stories complexes.  Si vous dédiez une séance de grooming entière à des stories complexes, vous aurez l’impression de ne pas avancer.

Cas d’urgence majeure:

Si vous devez rééllement planifier vos user stories pour le prochain sprint. Essayez d’en groomer au moins une ou deux. Essayez également de re-plannifier un backlog grooming dans l’après midi avec les ajustements apportés.

Ce n’est pas idéal mais ça peut passer à condition que ça ne se reproduise pas trop souvent.

Quelques repères :

A quelle fréquence je dois organiser une cérémonie de backlog grooming ?

Aussi souvent que vous le pouvez. N’ayez pas un rituel du genre une fois par semaine.

Cela n’a pas de sens. A chaque fois que vous avez des user stories en préparation qui demande la validation de votre équipe, organisez une petite séance.

A contrario, faites preuves de bon sens. Assurez-vous d’avoir de la matière à débattre, c’est à dire quelque chose de déjà bien défini. N’interrompez pas votre équipe à tout bout champs pour une question.

Combien de temps doit durer une cérémonie de backlog grooming ?

1 heure c’est l’idéal. 90 minutes au max. Au delà, vous allez perdre l’attention de l’audience. Le backlog grooming est une cérémonie assez fatigante intellectuellement car elle demande beaucoup de focus.

Evitez aussi de la planifier avant un long week-end ou en fin de journée si votre agenda le permet.

Dois-je utiliser le planning Poker  ?

Utilisez le planning poker avec un jeu de carte ou ce que vous voulez.

Estimez en durée plutôt qu’en effort si vous le préférez.

Vous avez même le choix de noter vos user stories en utilisant la business value.

A la limite peu importe. Tout dépend de la politique agile de votre organisation ou de vos préférences.  Le seul but de l’estimation est de trouver un accord compris et accepté par tous.

Dois-je prioriser mes users stories au moment du backlog grooming  ?

A mon avis non.  Vous devriez avoir la priorité de vos stories avant d’arriver dans la séance.

Il se peut qu’en cours de grooming, vous devez réévaluer l’ordre de priorités des user stories en fonction de votre conversation avec l’équipe.

Dans la majorité des cas, la priorisation se fait en évaluant la business value ou l’impact client de la story.  C’est à vous de le faire.

Puis-je groomer des stories 4 à 5 sprints à l’avance ?

Pourquoi pas. Si c’est votre cas, cela va dire que vous avez pris de l’avance. Félicitation !

L’inconvénient c’est qu’au moment du sprint planning, les stories que vous allez planifiés ne seront plus fraîches dans l’esprit de vos collaborateurs.

Vous allez devoir les ré-expliquer, et doubler votre effort.

L’autre question à se poser est : “Si une story peut attendre 4 ou 5 sprint, est-elle vraiment importante ?

À vous de voir.

En conclusion:

Je m’arrête là pour le backlog grooming. Il y aurait encore 1000 choses à dire tellement cette cérémonie est le pilier du métier de product owner.

Retenez juste que c’est le moment où vous devez communiquer votre vision produit et le moment pour fédérer votre équipe.

Les estimations ne sont qu’une conséquence d’une conversation constructive bien mené. Ne vous focalisez pas sur la quantité des stories groomer.

Mettez toute votre énergie dans la cohésion de votre discours et assurez-vous que votre équipe soit alignée avec votre vision.

Bon grooming.