Après Jimmy, c"est Élodie qui a commenté mon billet la vie de la story. Elle me fait des remarques très intéressantes, j'y réponds en dessous, dans un ordre revu.

Élodie :

J'imagine que c'est une simplification, un workflow idéal... mais il donne impression que toute idée aboutira... je serais plus à l'aise avec quelques "portes de sortie" pour prendre en compte les depriorisations, les risques, les imprévus...

Dans une autre vie, il y a plus de 15 ans, j'ai fait de la modélisation de processus en UML ou BPMN, il y avait plein de branches et de boucles… L'agilité m'a appris à simplifier. La finalité du modèle à 5 états que je propose est sa représentation, puis son utilisation sous forme de bacs (ou colonnes). Le management visuel (kanban) pousse à représenter tout process de façon linéaire, de la gauche vers la droite. C'est donc comme tout modèle, une simplification de la réalité. Mais…

Je verrais bien une sortie vers la poubelle au niveau de l'affinage. Oui, je pense qu'il faut savoir renoncer ^^

Bien sûr. Lors de ma présentation à LeanKanbanFrance 2015, j'avais montré ce slide —avec poubelle :

Options et engagement

C'est le rôle du PO de faire en sorte que des options soient explorées, puis abandonnées si elles apportent peu d'impact. Il est donc normal de jeter à la poubelle des stories à partir du bac à sable, ou qui sont en affinage, voire même, exceptionnellement, qui sont prêtes.

Du coup, plus de boucle ?

Dans une approche flux Kanban, la boucle est embêtante, elle peut conduire à violer une limite. On évite de revenir en arrière, de remonter le flux.

Imaginons une story "done", mais qui n'est pas acceptée à la démo (quelle qu'en soit la raison). Quel serait alors son état ?

Le guide Scrum est très clair au sujet de la revue : • L’Équipe de Développement fait la démonstration du travail qui est « Fini ». Il ne s'agit pas d'une revue formelle où une autorité accepte ou pas. Le cas que tu imagines n'arrive pas.

Personne d'extérieur à l'équipe n'a le droit de considérer ce que l'équipe considère fini comme pas fini. Seule l'équipe peut reconnaitre s'être trompée, c'est pourquoi dans iceScrum il y a bien longtemps, nous avions prévu de pouvoir repasser une story finie à en cours tant que le sprint n'est pas clos. C'est une boucle alors cela doit rester exceptionnel.

Ou alors la notion de "fini" inclus l'acceptation par le PO ?

Oui. À mettre de façon explicite dans la définition de fini si ce n'est pas implicite dans l'équipe.

Et si on n'arrive pas à la finir ? Je verrais bien aussi une flèche de la réalisation à l'affinage si on ne n'arrive pas atteindre le Done.

C'est pas fini, et en général reporté au prochain sprint. La story reste en cours.

Et si on considère que l'acceptation n'est pas dans la DoD et se joue en demo il faudrait une étape supplémentaire ça ferait donc 1 étape et 1 état en plus...

Cela ne peut pas arriver car :

  1. on ne montre que ce qui est fini à la démo
  2. fini inclut l'acceptation (qui est là pour confirmer que la story est finie, un des 3C)

Et la revue n'est pas prévue pour ça.

Merci Élodie.