Product Owner à la découverte du découpage en tâches

Si je découpe des User Stories au quotidien depuis toujours, j'ai découvert récemment le découpage en tâches et l'intérêt que ça pouvait avoir pour un Product Owner.

Le découpage des User Stories trop grandes

Au quotidien le Product Owner découpe des features en User Stories, des User Stories trop grandes en User Stories suffisamment petites pour entrer dans un sprint. Découper devient un réflexe pour le Product Owner. Le besoin initial pitché en atelier est ensuite découpé en features lors du Story Mapping et se retrouve finalement découpé en des dizaines de User Stories prêtes à remplir des sprints. (Pour la naissance d'une User Story c'est par là-bas).

Idéalement, un sprint doit être composé de petites User Stories ne dépassant pas les 2 ou 3 jours de développements. L'objectif étant qu'un développeur puisse travailler sur plusieurs sujets au cours du sprint, que le Product Owner puisse tester au fil des jours, que le burndown chart descende progressivement et non par à-coup. Toutefois, il arrive qu'il ne soit pas possible de découper aussi finement.

Imaginons un sprint où il y aurait autant de User Stories embarquées que de développeurs. Où chaque développeur serait sur son silo. Où le burndown chart stagnerait. Où le Product Owner manquerait de visibilité. Le résultat obtenu serait un mini Cycle en V.
Existe-il tout de même un moyen pour découper ces User Stories ?

Une Definition of Done qui aide au découpage

Tout part de la Definition of Done définie et affichée par l'équipe en haut du Scrum-board. Pour pouvoir être livrée au Product Owner, une User Story doit respecter chacun des items de la Definition of Done. Dans mon équipe, elle doit, entre autres, être passée par les tâches suivantes :

• code review
• tests d'intégration
• prise en compte des retours de validation
• préparation de la démo
• suppression de la branche

En effet, nous avons défini qu'une User Story peut être livrée au Product Owner uniquement si elle a été reviewée et testée en intégration et non uniquement en local. Elle est ensuite considérée comme Done quand il n'y a plus aucun retour dessus et qu'elle est prête à être démontrée au Métier.

De ce premier découpage en tâches récurrentes est venu rapidement un découpage en tâches techniques de chaque User Story.

Lors du sprint planning, une fois la User Story et les BDD présentés, les développeurs discutent et découpent en tâches techniques pour chiffrer au plus juste. Le travail de conception commence dès le sprint planning.

Quel intérêt pour le Product Owner ?

Mêmes si ces tâches dépendent les unes des autres et qu'elles ne sont pas testables individuellement, ce découpage apporte plusieurs intérêts et pas uniquement pour les développeurs.

Avec ce découpage en tâches, exit la User Story qui dure tout le sprint bloquant le développeur sur un sujet unique pendant toute la période. Exit les daily meetings monotones et empêchant la visibilité au fil des jours. Exit l'effet tunnel. Bienvenue à l'organisation et à la production rapide de valeur.
Une grande User Story n'est plus un risque, elle permet à plusieurs développeurs de travailler sur un même sujet, elle permet l'échange et le challenge. Chacune de ses tâches vit au board. La visibilité amenée par le découpage permet d'anticiper et d'éviter les risques.

Dans notre équipe, nous avons choisi de chiffrer la User Story et non les tâches pour éviter des séances de chiffrage à rallonge. Le chiffrage est lissé sur les tâches et, chaque matin, c'est le reste à faire de chaque tâche qui est ré-estimé.

Une tâche dépasse rarement les 2 jours de travail permettant à chaque développeur de changer de sujet régulièrement et de participer à l'intégralité du scope du sprint, montant ainsi en compétence sur tous les sujets.

Si les tâches ne sont pas testables individuellement, ce découpage permet une plus grande maîtrise du sprint et de son organisation, le Product Owner peut anticiper les User Stories "done" et s'organiser pour les tester et faire ses éventuels retours.

Un burndown chart en tâches ou en User Stories ?

Dans mon équipe le Burndown Chart est mis à jour avec le chiffrage des tâches et, en fin de sprint, une User Story non finie n'est pas comptabilisée à zéro mais au nombre de points terminés. Elle reste "not done" mais dérape sur le sprint suivant uniquement via son Reste-à-faire et ses tâches non terminées.

Je trouve que ce Burndown Chart en "tâches" permet, un meilleur suivi du l'avancement du sprint, la courbe descend régulièrement au fil de l'eau.
Pour autant il ne faut pas tomber dans la dérive et finir un sprint avec un maximum de points mais où toutes les User Stories sont commencées mais non terminées.
A ce Burndown Chart en tâches je rajouterais donc l'indicateur du nombre de User Stories "Done" du sprint.

Le but d'un sprint est de produire de la valeur et non des points.

Et vous ? Comment gérez-vous et suivez-vous les grandes User Stories ?