Backlog et workflow des stories

Le backlog contient des éléments, qui ont chacun leur cycle de vie.

Pour être plus explicite, plutôt qu'élément du backlog de produit, j'utilise story. Le backlog de produit contient donc des stories.

La vie d'une story se déroule de la façon suivante :

  • un jour, elle est suggérée par quelqu'un qui a une idée
  • le Product Owner, qui est finalement le responsable du contenu du produit, examine les stories suggérées et les acccepte -ou pas- pour qu'elles soient développées et ajoutées au produit
  • Une fois acceptées, les stories sont estimées par l'équipe qui évalue l'effort de développement nécessaire
  • Les stories peuvent alors être planifiées, c'est à dire associées aux sprints dans lesquels on prévoit de les réaliser
  • Lorsqu'arrive le sprint, les stories qui y sont associées deviennent "en cours"
  • Et si tout se passe bien, elles seront finies à la fin du sprint.

Workflow d'une story

On peut mettre toutes les stories, quel que soit leur état, dans le backlog de produit, en le considérant comme un conteneur. Cette solution a des inconvénients:

  • le backlog peut alors contenir beaucoup d'éléments et il faut mettre en place des filtres pour s'y retrouver
  • cela pousse à traiter toutes les stories de façon uniforme alors que, selon l'état courant, l'usage est différent

Dans mon livre (page 63), j'identifie 4 usages différents, extrait :

Selon l’état des stories, on peut identifier quatre grandes parties dans un backlog, selon les accès : une personne qui veut savoir ce qui est en cours de développement dans le sprint en cours filtrera le backlog uniquement sur les stories en cours ; quelqu’un qui veut connaître les prévisions à moyen terme est intéressé par les stories planifiées, qui constituent le plan de release ; le Product Owner dans son travail d’anticipation sur les futurs sprints[1] va consulter la partie du backlog qu’il faut peut-être décomposer, compléter ou estimer ; tout le monde peut avoir envie de connaître les stories finies dans les sprints passés.

J'y ajouterai maintenant un 5ème, permettant à tous, même s'ils ne font pas partie de l'équipe, de suggérer des nouvelles stories. Une sorte de bac à sable.

Pour faciliter ces usages, l'accès peut être différencié par état plutôt que de tout chercher dans un gros backlog.

Le plan de release montre les stories planifiées. Comme il garde une trace du passé, il permet aussi de connaître les stories finies dans les sprints précédents et celles en cours. On retrouve également ces dernières dans le tableau des tâches (ou backlog de sprint).

Si on met en place un bac à sable permettant de proposer des stories, le "vrai" backlog ne contiendra que les stories acceptées par le Product Owner, estimées ou pas, et en attente de planification dans la release. Un backlog ainsi constitué restera limité en taille, il ne devrait pas dépasser une cinquantaine d'éléments.

Workflow et backlog

C'est cette approche qui est mise en place dans la nouvelle version d'iceScrum.

Notes

[1] je m'aperçois qu'il manque le s final dans le livre, je l'ajoute aux errata pour la 2ème édition

Commentaires

1. Le jeudi 22 juillet 2010, 11:08 par Sylvain

Bonjour Claude,

je préfère clairement ta dernière vision présentant les stories dans des "containers" différents (Bac à sable, Backlog de produit, Plan de release, Sprint en cours) en fonction de leur état.

En effet, dans la première vision suggérant un seul "container" (Backlog de produit) dont il faudrait "filtrer le contenu" est une vision clairement dirigée par l'usage un outil informatique.
Pas facile de filtrer lorsqu'on utilise des fiches bristol…

A prioiri, Scrum est un framework. L'usage d'un outil informatique n'est pas obligatoire. Cette dernière vision permet ainsi, par exemple, de classer les fiches bristol dans différents classeurs en fonction de leur état, chacun des classeurs représentant le Bac à able, le Backlog produit, le plan de release ; les stories en cours sont, quant à elles, collées au tableau…