Le bac à sable

Bac à sable (source Wikipedia) Le backlog (de produit) est la liste de toutes les choses qui entraînent du travail à faire par l'équipe.

Le bac à sable est l'antichambre du backlog.

Cette nuance entre des stories proposées, dans le bac à sable, et des stories acceptées, dans le backlog, met en exergue le rôle du Product Owner. C'est lui qui, après avoir consulté autant que nécessaire, décide de la sortie du bac à sable.

Comme dans les encyclopédies collaboratives, par exemple Wikipedia, l'intérêt d'avoir un bac à sable est d'élargir la communauté des personnes qui participent à l'élaboration du backlog. On n'a pas peur de jouer dans un bac à sable et on y propose plus facilement son feedback et ses idées.

C'est cette croyance dans une plus grande collaboration qui nous a conduits à proposer un bac à sable dans iceScrum (j'avais proposé de l'appeler bac à glace).
Voir aussi sur le sujet : Backlog et workflow des stories.

Que met-on dans le bac à sable ?

On y met des trucs à faire pour le produit. Cela peut-être des propositions de nouveautés, d'évolutions, de corrections de défauts... Tout ce qui peut contribuer à l'amélioration du produit. Comme cela a vocation à rejoindre le backlog, on va aussi appeler ça des stories.

Qui peut contribuer dans le bac à sable ?

Tout le monde. Les membres de l'équipe bien sûr, mais aussi d'autres en dehors de l'équipe. Tous ceux qui ont une idée peuvent proposer une story dans le bac à sable. C'est pour cette raison que son accès doit être facile.

Quelle est la vie d'une story dans le bac à sable ?

Ca dépend, mais un bon Product Owner ne laissera pas les stories s'accumuler dans le bac à sable. Il accepte ce qui est utile, rejette ce qui ne l'est pas et discute avec celui qui a soumis la story quand des éclaircissement sont nécessaires. Si la discussion ne peut pas se faire en face à face à cause de l'éloignement géographique, on utilisera des annotations ou on donnera des informations par des fichiers annexes attachés à la story. Le dialogue continue jusqu'à ce que le Product Owner soit en mesure de prendre sa décision.

Dans quel cas le Product Owner peut rejeter une story ?

Le Product Owner a, normalement, une bonne connaissance du produit. Il peut identifier des propositions qui sont des doublons et qu'il supprimera. C'est aussi son rôle de décider et il peut refuser des propositions qui ne lui paraissent pas intéressantes pour le produit.

Que se passe t-il quand le Product Owner accepte une story ?

Une story qui était dans le bac à sable et qui est acceptée par le Product Owner en sort. Le cas usuel est qu'elle soit transférée dans le backlog de produit. Elle continue sa vie de story.
Parfois une proposition est relative à une notion de plus haut niveau qui correspond à une feature plutôt qu'une story. Le Product Owner va dans ce cas, accepter la proposition qui rejoindra la liste des features.
Un troisième cas peut se produire dans certains contextes où on accepte de traiter des urgences pendant le déroulement d'un sprint. Si la suggestion faite dans le bac à sable s'avère urgente à tel point qu'il faille la réaliser dans le sprint en cours, le Product Owner a la possibilité de la transformer en tâche urgente. Elle apparaîtra directement dans le plan de sprint de l'équipe. Ce fonctionnement peut être cadré en limitant le nombre de tâches urgentes[1] par sprint, c'est la notion de TAF (ou WIP en anglais).

Peut-on importer des stories dans le bac à sable ?

Si on dispose déjà d'un paquet de stories potentielles, par exemple dans un bugtracker ou une feuille de calcul, il faut pouvoir les importer dans le bac à sable. Avec iceScrum,cela se fera soit en utilisant le service web qui va bien, soit par l'intermédiaire d'un fichier xml, soit directement à partir d'une feuille de calcul, en faisant glisser la sélection de stories dans la fenêtre bac à sable d'iceScrum.

Notes

[1] je reviendrai sur les tâches urgentes dans un prochain billet

Commentaires

1. Le mardi 07 septembre 2010, 05:57 par François Michas

Une vraie idée aussi pour collecter les besoins auprès des commanditaires dont la disponibilité est toujours un point sensible.
Le bac à sable outillé avec un wiki est certainement un très bon outil pour le PRODUCT OWNER. Il permet une collecte interactive des besoins auprès des métiers que le PRODUCT OWNER représente avant de les fédérer ultérieurement en face à face, préférable pour une meilleure compréhension.
Merci.