Travaux pour préparer le backlog

Le Product Owner, et aussi toute l’équipe, doivent anticiper le prochain sprint pendant le sprint courant.

Pour qu’un sprint commence dans de bonnes conditions, il convient que chaque story qui rentre dans ce sprint soit prête[1].

La signification de prêt pour une story dépend de l’équipe (comme la signification de fini). En général, cela implique que la story soit estimée, suffisamment petite pour tenir dans le sprint et suffisamment comprise par l’équipe pour être développée.

C’est l’équipe qui décide si une story est prête. Le meilleur moment pour le faire est la réunion de planification de release (que j’appelais autrefois revue de backlog), qui a lieu quelques jours avant le début du prochain sprint.

C’est le Product Owner qui, en bichonnant son backlog, fait en sorte que les stories soient prêtes. Les travaux consistent à décrire la story, éventuellement en lui associant des storytests (qui constituent sa spécification). Le Product Owner peut se faire aider par des membres de l’équipe pour y arriver.

Ces travaux de préparation sont réalisés dans le sprint n pour des stories qui seront réalisées dans le sprint n+1 (voire plus tard). Le temps passé sur ces travaux n’est pas négligeable, cela peut aller jusqu’à 10% de la boite de temps allouée à un sprint.

J’insiste sur cette nécessité d’anticipation quand je présente Scrum dans mes formations. Lors de la dernière, la semaine dernière, un participant m’a demandé si ces travaux devaient apparaitre explicitement dans le tableau des tâches du sprint.

J’ai répondu que non, les travaux d’anticipation sur les stories du sprint suivant n’apparaissent généralement pas comme des tâches du sprint courant. A la réflexion, je me suis dit que c’était peut-être la raison pour laquelle ces travaux n’était pas faits à temps ou mal faits : les équipes se focalisent sur les stories à finir dans le sprint et oublient les stories à préparer.

Si on veut les faire apparaître explicitement, ce serait sous quelle forme ?
On pourrait créer une tâche de préparation pour chaque story à préparer et les traiter comme les autres tâches du sprint. A noter que les stories à préparer pendant le sprint n ne sont pas (en tout cas pas toutes) connues lors de la réunion de planification du sprint n, ce qui conduirait à considérer ces tâches de préparation comme des tâches urgentes.

Une autre possibilité, évoquée par Serge Beaumont dans un billet traduit par Fabrice[2], est de représenter visuellement le workflow de la story[3] dans un tableau kanban.

Notes

[1] D’ailleurs ne devraient être sélectionnables pour un sprint que les stories prêtes

[2] dont on ne dira jamais assez combien ses traductions sont précieuses

[3] Dans mon billet, on trouve l’état Planifié et pas l’état Prêt et c’est aussi ce qu’on trouve dans l’outil IceScrum. Dans une prochaine version, ce sera bien Prêt (ready).