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 :

La vie de la story a changé en 10 ans

Il y a à peu près 10 ans, j'écrivais un billet "Les états significatifs d'un élément de backlog".

Amusant de le relire aujourd'hui et de constater comment mon approche de Scrum a —légèrement— évolué au fil des ans.

Pas beaucoup sur les états, car je décris toujours la vie d'une story avec cinq états, dont les noms ont un peu changé, mais pas les 2 essentiels : prêt et fini.

Depuis l'édition 3 de mon livre j'en reste à ce workflow pour une story :

La vie de la story

C'est ce qui a donné naissance à la présentation du backlog en bacs, qui sont consolidés dans l'édition 4.

J'en reviens aux changements depuis le billet de 2007 :

  • je dis story, c'est plus court qu'élément de backlog
  • identifié est devenu idée, truc qu'on met dans le bac à sable
  • estimé est remplacé par en affinage (cette notion n'existait pas en 2007). Je considère maintenant l'estimation comme une activité, optionnelle, de l'affinage
  • mon schéma de 2007 montre une boucle si la décision de ne pas accepter la story comme finie est prise. Je mentionnais que cela se faisait lors de la revue de sprint. C'est là le changement le plus notoire : on n'attend pas la démo pour déclarer une story finie. Au contraire, on ne montre à la revue qu'une story déjà déclarée finie.
  • la revue de backlog dont je parlais s'appelle maintenant l'affinage (revue de backlog était pas si mal)
  • dans ce billet de 10 ans, je disais qu'une story passait de prête à en cours lors de la planification du sprint. Maintenant je dirais qu'elle reste prête tant qu'on ne travaille pas dessus. Si on commence la story au 8e jour du sprint, elle change d'état à ce moment-là.

Ces 2 derniers points illustrent l'évolution vers du flux : ce ne sont pas les événements Scrum (planif, revue) qui ont un impact sur l'état de l'ensemble des stories. Chacune a sa vie indépendante. C'est ce qu'on retrouve dans Scrum3.0.

Exprimer et formaliser le besoin, le Cube

Logo cube SpécifierLe Cube à emporter de 1CUBE&GO, que j'anime à Toulouse le 13 décembre, s'intitule "Exprimer et formaliser le besoin".

Il est destiné à toutes les personnes qui s'intéressent à découvrir, faire émerger, comprendre, analyser, transmettre et développer le "besoin" pour en faire le bon produit.

Lire la suite...

Les 6 activités de l'affinage du backlog

Il y a tout juste un an, je consacrais beaucoup de mon temps à l'écriture de Scrum#4. Des efforts récompensés, cette nouvelle édition a finalement été publiée en octobre et, depuis, elle s'écoule bien : nous avons dépassé les 2000 exemplaires en mai et elle est toujours bien classée chez Amazon.

Amazon 13 juin 2016 8h

L'édition 4 comporte de nombreuses nouveautés. En particulier, apparait un chapitre dédié à l'affinage du backlog.

Lire la suite...

Une après-midi révélatrice de ScrumMaster

Dans l'édition 4 de mon livre, j'ai ajouté des histoires pour raconter une journée typique d'un ScrumMaster et d'un Product Owner.

Voici la deuxième partie avec un extrait tiré du chapitre 5 Le rôle du ScrumMaster.

Lire la suite...

La vie d'une story

Les 5C +1

Après les 6D, les 6C.

Lire la suite...

Décider qu'une story est prête

6D1.png

Lire la suite...

Glossaire R-S

couverture Scrum éd.4

Dans l'édition 4 de mon livre, j'ai ajouté un glossaire. C'est une des nombreuses nouveautés.

Lire la suite...

Le story mapping, ma préface

Le livre de Jeff Patton a été traduit pour une publication chez Dunod. En français, le titre est simplement "Le story mapping".

Livre "Le story mapping"

Lire la suite...

- page 1 de 4