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 Manager.
Le découpage des User Stories trop grandes
Au quotidien le Product Manager 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 Manager. Il est possible, par exemple, de découper et prioriser un besoin initial à l’aide d’un atelier de story mapping. Ce besoin se retrouve alors découpé en des dizaines de User Stories prêtes à remplir des sprints (l'article sur la naissance d'une User Story est également disponible).
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 Manager 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 Manager 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
Avant qu’une User Story puisse entrer dans le pipe de développement, elle doit correspondre à certains critères constituant la “definition of ready” (ou DoR). La DoR peut être variable selon chaque équipe, mais la plupart du temps, une User Story qui suit la DoR contient des règles métiers explicites, des maquettes prêtes, des critères d’acceptation définis et pour finir, la Story a été affinée. Notre Story est alors prête à partir en développement !
Pour pouvoir être livrée au Product Manager après son développement, 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 Manager 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 Manager ?
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 Manager 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. En effet, le burndown chart doit rester un indicateur de progression et non pas un élément remettant en question la productivité d’une équipe. Une tâche très complexe pourra impacter la courbe en fin de sprint sans que la vélocité ou la productivité de l’équipe ne puissent être remises en question.
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 ?
