Dans « Extreme Programming Installed », Ron Jeffries, en 2001, définit la vie de la story avec trois phases : la carte comme moyen de l’identifier, puis une conversation et enfin une confirmation. Cela est connu comme les « 3C »[1].

En fait, l’équipe déroule deux cycles de conversation et confirmation : un premier pour obtenir une story prête, un second pour que la story soit finie, donc nous avons les « 5C » :

  1. Un jour, quelqu’un a une idée de story et la note sur une Carte (maintenant on utilise plutôt un post-it).
  2. Le Product Owner et l’équipe affinent cette story, afin qu’elle puisse être réalisée en un sprint, au cour de Conversations.
  3. L’équipe apporte sa Confirmation qu’elle est prête.
  4. L’équipe réalise la story pendant un sprint, en tenant de nouvelles Conversations avec le PO sur son acceptation.
  5. Le Product Owner apporte sa Confirmation qu’elle est finie.

Dans la vie de la story, il y a ces deux grandes phases de travail collectif basées sur des conversations : celui, bien connu, de réalisation pendant un sprint et l’autre, encore moins connu, d’affinage dans des sprints antérieurs. Entre ces deux travaux non consécutifs, la story est en attente. Elle est prête, au sens où elle peut être réalisée dans un prochain sprint.

En se basant sur ces « 5C », on peut représenter le workflow de la story :

La vie de la story On ne traite pas de la même façon une story au stade de l’idée qu’une story prête. L’affinage nécessite une identification claire des stories. Cela pousse à ranger les stories dans des dépôts correspondant à leur état. Nous les appelons des bacs, en référence au backlog.