L’importance du Backlog Grooming

Lorsque j’ai intégré un nouveau projet il y a un mois, j’ai découvert que l’équipe que je rejoignais ne connaissait pas et donc n’organisait pas de « Backlog Grooming ».

Le premier Sprint Planning auquel j’ai participé a duré 3 heures. C’est long. C’est barbant. Les participants se sont rapidement désintéréssés. L’atelier a rapidement empiété sur la pause déjeuner. Au secours.
En sortant de la salle (enfin!), je leur ai demandé « mais comment vous faîtes pour supporter ça ? ». L’un d’entre eux m’a répondu « et encore, avant ça nous prenait la journée entière… ». #Help!

Au delà d’être une corvée pour tout le monde, un Sprint Planning où les débats sont sans fin entraîne le risque d’embarquer dans le sprint des User Stories qui ne sont pas prêtes. Ou de passer à côté de certaines subtilités. Un autre exemple : je me suis rendue compte que l’équipe ne rédigeait pas de scénarios de tests pour chaque Story. Une fois la fonctionnalité développée, le testeur demandait donc au développeur « comment tester » avant de suivre ses consignes à la lettre et passer la tâche en « Done ». La probabilité de passer à côté de certains cas fonctionnels et d’engendrer des régressions était donc décuplée.

Je leur ai donc proposé de mettre en place 2 ateliers de Backlog Grooming par sprint, pour partager les sujets du backlog, échanger sur les prochaines fonctionnalités à développer, découper les User Stories, et surtout, en finir avec les discussions interminables au moment de démarrer un nouveau sprint.

« Oui, mais si on fait 2 backlog grooming d’une heure et un sprint planning d’environ une heure et demie, au final ça revient au même qu’un sprint planning de 3 heures ? ». Non ! Parce qu’on échelonne les discussions sur plusieurs jours. On prend le temps de laisser décanter nos réflexions. Et on peut aller chercher des informations supplémentaires auprès des interlocuteurs qui ne participent pas à nos cérémonies, pour affiner les sujets. Bref, on gagne en qualité.

La mise en place d’un Backlog grooming récurrent, d’une heure pas plus, c’est la garantie de démarrer un nouveau sprint avec des User Stories qui sont d’avantage formalisées et partagées. L’ensemble des membres de l’équipe sait concrètement ce qu’il faudra faire pour chaque Story. Les estimations de chaque tâche sont affinées. Et le risque de surcharger le sprint parce que tous les impacts n’ont pas été étudiés est diminué.

Quel résultat ?
4 ou 5 Backlog Grooming et 2 sprints de développements plus tard, l’équipe est satisfaite de ce nouveau mode de fonctionnement. Le bénéfice de cet atelier est ressorti plusieurs fois comme un point positif au moment de la rétrospective.
Et bien que le fruit de ces ateliers n’ait pas engendré une amélioration nette de la vélocité de l’équipe, nous constatons clairement d’avantage de sérénité dans le déroulement des sprints.
A long terme, l’équipe pourra également avoir une meilleure visibilité du Backlog du Produit, notamment sur les sujets à venir dans 2 ou 3 mois
Et surtout, l’équipe ne sacrifie plus ses pauses déjeuner !

D’autres articles utiles sur le sujet :
● Pour que les Backlog Grooming ne soient plus une corvée ! ▫TheObserverself
● Backlog Refinement, la clé pour une Agilité réussie ▫QualityStreet