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.

La vie de la story selon Jimmy

Suite à mon billet d'hier, j'ai reçu un commentaire de Jimmy L. que je remercie de son feedback.

Jimmy est tout à fait d'accord avec moi pour ne montrer à la revue qu'une story déjà déclarée finie. Cependant il enchaîne :

…Mais cela m'étonne justement qu'on s'arrête généralement à "Finie" sur ce genre de workflow, et qu'on ne mette pas au moins en bout l'état correspondant à l'avis positif reçu en revue de sprint.

Non. Voilà pourquoi : fini est forcément le dernier état du workflow, sinon c'est pas fini. Plus que fini, ça n'a pas de sens. C'est une autre histoire.

Avec plus de détails :

Jimmy ne parle que d'un avis positif, je comprends que son idée est que la story continue jusqu'à la revue même si elle est finie avant. Soit, mais la revue fait partie du "process", l'équipe sait qu'elle doit y montrer les stories finies. Pas besoin d'un état sur chaque story pour cela, s'il faut vraiment penser à préparer la démo, je suggère plutôt d'ajouter une story de préparation de démo tant que c'est nécessaire.

L'avis (positif ou négatif) sollicité à la revue auprès des parties prenantes s'appelle le feedback. Il est le bienvenu et peut conduire à ajouter une nouvelle story, mais pas à faire revenir la story en arrière (c'est à dire à considérer qu'elle n'est plus finie).

À méditer pour la prochaine fois : et si dans sa définition de fini pour une story, Jimmy avait "avoir reçu un avis positif lors de la revue" ?

Jimmy poursuit :

J'avais tendance à appeler cet état "Acceptée" mais cela est ambigu lorsque le client fait ensuite une phase de recette approfondie (souvent appelée User/Fonctional Acceptance Testing). Du coup, j'opte pour l'état "Revue" après le "Finie".

Oh ! Une phase de recette par le client. Scrum ? mon scrotum !

Bon, il va me falloir au moins un autre billet pour y répondre. Cela concerne plusieurs aspects souvent mal compris dans Scrum :

Chapitre onze

Dans la série Suppléments en ligne de mon livre sorti, pour la première édition, il y a 4 ans, voici la Définition de fini qui constitue le chapitre 11 de la troisième édition.

Lire la suite...

Les conditions de réalisation

Une story est prête à prendre le départ du sprint si son comportement attendu (conditions d'acceptation) et la qualité requise (critères de finition) sont suffisamment connus de l'équipe. Un autre volet essentiel pour s'assurer de la capacité de l'équipe à développer la story pendant le sprint porte sur les conditions de réalisation.

Les 3 composants d'une story

Lire la suite...

Quiz agile, retour sur les questions 13 à 15

Les 3 dernières questions des 15 du quiz placé à la fin de mon livre Scrum.

A propos de quiz, il y en aura un qui sera proposé à la fin de la formation Kanban du 24 octobre, comme dans mes formations Scrum, en plus court.

Lire la suite...

Retour sur le quiz agile, questions 9 à 11

Voici 3 questions, avec les liens vers les billets présentant les réponses, parmi les 15 proposées à la fin de mon livre et qui ont été présentées sur mon blog l'an dernier :

Lire la suite...

La pratique "Définition de prêt pour une story"

La définition de fini est une pratique maintenant bien connue. La pratique symétrique, la définition de prêt, l'est beaucoup moins.

Lire la suite...

Quizz, la dernière question

La question était :

3 équipes Scrum participent au développement d’un seul produit, chacune s’occupant d’un ensemble de features. Comment gérer la signification de fini ?

Lire la suite...

Quizz, la question 10 sur la signification de fini

La question était la suivante :

La signification de fini dit que les tests de performance doivent être passés à chaque sprint. L’équipe n’y arrive pas. Que faire ?

Lire la suite...