Kane MarSuite à une discussion sur les activités liées à la préparation d'un backlog produit (avec Mathieu, l'un de mes collègues agilistes), j'ai traduit cet article de Kane Mar[1] qui nous décrit la réunion Story Time : "STORY-TIME! THE HIDDEN SCRUM MEETING".

Est-ce que votre équipe a des difficultés à prévoir lorsque le projet sera terminé ? Avez-vous un grand nombre de stories non-estimées dans votre backlog produit ? Vos réunions de planification traînent-elles longuement sur plusieurs journées en générant beaucoup de discussions ? Si c'est le cas, il se pourrait que vous ayez tendance à oublier de "nettoyer" régulièrement votre backlog produit.

Ken Schwaber conseille généralement que l'équipe consacre cinq pour cent de son temps (à chaque sprint) sur la préparation du backlog. Ce procédé est généralement connu sous le nom de "nettoyage"[2] ou maintenance. Voici une bonne définition de ce que cela implique :

Il y a beaucoup de choses que l'on fait dans le backlog pour préparer les futurs travaux. On ajoute de nouvelles stories et epics[3], on découpe des epics en stories, on estime, on ajoute la valeur métier espérée, et ainsi de suite. Dr. Dan Rawsthorne, CST

J'ai récemment travaillé avec plusieurs clients qui approuvent la recommandation des cinq pour cent de Schwaber, mais qui en fait ne l'applique pas. Ils comprennent bien qu'ils ont besoin de passer cinq pour cent de leur temps sur la maintenance du backlog, mais ils ne le font pas et, par conséquent, leurs réunions de planification deviennent tendues et très longues.

Depuis plusieurs années, je préconise explicitement la maintenance du backlog comme faisant partie intégrante du processus Scrum. Je conseille aux équipes de tenir périodiquement une réunion de deux heures chaque semaine. C'est une occasion de discuter et de maintenir le backlog, de sorte que la réunion de planification puisse être aussi efficace et productive que possible. J'appelle ces réunions "Story Time". Ce n'est pas un nouveau concept. Quand je travaillais exclusivement avec des équipes XP il y a plusieurs années, il était de pratique courante de tenir régulièrement une réunion Story Time. Bien que ça ne fasse pas officiellement partie de Scrum, j'ai découvert que le Story Time améliorait grandement la planification des projets et diminuait significativement les risques de discussions interminables qui apparaissent trop souvent dans de nombreuses équipes.

Une réunion Story Time devrait se tenir à la même heure et au même endroit chaque semaine et impliquer toute l'équipe, y compris le Product Owner et le ScrumMaster. Le seul but de ces réunions hebdomadaires est de travailler sur le backlog produit pour préparer les futurs travaux. Ceci peut aussi inclure l'ajout de nouvelles stories et epics, le découpage de grosses stories et l'estimation.

Donc, si le Product Owner et les Développeurs de votre équipe passent la majorité du temps de la réunion de planification à discuter sémantique, essayez les réunions de Story Time pour vous permettre d'être plus efficace dans vos prévisions. Je serais curieux de savoir comment cela impacte votre métier au jour le jour.


Kanban signRetrouvez l'intégralité de mes traductions sur le wiki Traductions Agiles.

Notes

[1] About the author: Kane Mar is an international Scrum Coach and Trainer, based in Australia. He has trained over 1000 people in over 30 countries, and worked with large multinational corporations such as Microsoft, Oracle, Telstra, and Capital One. His blog on Scrum and software can be found here: Scrumology Pty Ltd

[2] NdT : grooming

[3] NdT : epics = grosses stories