La vie de la story selon Elodie

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.

Commentaires

1. Le vendredi 30 juin 2017, 18:00 par Elodie

Merci beaucoup pour cette réponse :)

Et merci pour le rappel sur la DoD incluant la validation du PO... ce n'est pas ce que je vois pratiqué au quotien et la piqûre de rappel est plus que bienvenue !!!

Juste deux remarques si ça ne vous dérange pas de continuer un peu la discussion...

J'ai plutôt tendance à considérer (peut être à tord) le sprint review comme, entre autre, un moment privilégié lors duquel les parties prenantes du projet/produit donnent du feeddback à l'équipe (ce n'est pas le seul moment, c'est pour ça que je parle de moment privilégié... )
Ce feedback peut être positif, ou négatif, on n'est pas à l'abri d'une mauvaise surprise... Et c'est normal ^^
Par exemple (vécu ^^) : développement d'une application métier. L'appli est utilisée par différents corps de métier, le PO priorisant les besoins de ces différents types d'utilisateurs. Des utilisateurs volontaires participent aux demos pour donner un avis direct. Lors d'une demo, un technicien fronce les sourcils et déclare que la nouvelle fonctionnalité n'est pas utilisable. Je passe les détails mais il avait raison et même rétrospectivement, je ne vois pas comment on aurait pu éviter le pb, puisque ce n'est qu'en manipant l'application qu'il s'en est rendu compte. Et c'est vraiment bien qu'on s'est soit rendu compte aussi tôt je pense, merci Scrum ^^
Bref. On n'a pas pu garder cette fonctionnalité bien sûr, elle n'a jamais été livrée en prod. Mais si, en imaginant de l'agilité ++ avec du devops, si la DoD représente vraiment un état fini (livré en prod) sans possibilité de "retour arrière" pour correctif ou autre avant livraison  "finale"... que faire des feedbacks potentiellement négatifs en démo ?

Deuxième exemple, (vécu aussi ^^)
On doit développer une API pour récupérer des données d'un autre produit. L'API que nous devons interroger est documentée, pas de difficultés particulières, la story passe en sprint.
En cours de sprint, l'API fournisseuse ne répond plus. Impossible de tester. On essaye de contacter l'autre équipe, le support... finalement ça va être beaucoup plus complexe que prévu et on perd du temps pour réaliser d'autres stories.
Finalement, compte tenu de ces nouveaux éléments  le PO renonce. La story aurait valu le coup si c'était simple. Mais pas assez de valeur pour y passer autant de temps.
Cette story aura été commencée... et jamais aboutie.
Encore cette histoire de renoncement et de portes de sorties...

Ceci dit... je comprends très bien la simplification et la référence à Kanban me parle beaucoup.
Avec ce point de vue je trouve le schéma très clair et je sais que ce dont je parle ne sont que des cas très particuliers. On ne va pas modéliser toutes les exceptions au risque de noyer ce qui est important...  la piqûre de rappel dont je parlais au début :)