Les types de story dans un backlog

Où il est question de story technique, un sujet controversé

Les types de story dans un backlog

La vocation du backlog étant de collecter tous les travaux de l’équipe qui apportent de la valeur, il n’est pas raisonnable de se limiter uniquement à ce qui est visible des parties prenantes.

Cette présentation des types de story reprend l’idée de Backlog in Colors proposée par Philippe Kruchten (qu’on trouvera dans ses slides sur la dette technique dont je conseille la lecture; elle donne du sens à cette notion souvent vague).

Elle se base sur 4 quadrants avec deux axes :

  • selon que la story ajoute de la valeur ou rétablit celle perdue,
  • selon que cette valeur est perceptible par les parties prenantes externes à l’équipe (valeur “métier”), ou seulement par l’équipe (valeur aussi, mais pas directement “métier”).

La story “technique” se justifie dans plusieurs situations :

  • il y a une décision technique à prendre sur la façon de réaliser une user story,
  • il y a un risque technique qu’on veut lever avant la réalisation d’une user story,
  • des travaux techniques, visant à améliorer la façon dont l’équipe développe ou la qualité : infrastructure, logistique, nouvel outil, formation, refactoring…

Pour ne montrer que de la valeur “métier” dans un backlog, on pourrait essayer de toujours inclure les travaux d’une story technique dans une user story. Ce serait totalement artificiel dans le dernier cas. Dans les deux premiers cas, cela reviendrait à prendre dans un sprint une story avec une grande incertitude sur sa terminaison. Ce qui n’est pas une bonne idée. Il me semble que c’est pour éviter ça que XP avait introduit il y a longtemps le spike.

Attention, dans les user stories il y a toujours des travaux techniques (conception, code) et c’est très bien. Il ne s’agit pas de faire une story technique pour chaque user story, en y mettant les travaux techniques.

Voir aussi :