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.

Flux dans le sprint et engagement

Suite à la lecture de mon billet Scrum3.0, Eric se demande, à propos du sprint en flux continu :

Le flux continu remet en cause le principe "pas de changement pendant un sprint". Comment permettre à l'équipe de s'engager dans ce mode de fonctionnement ? Au jour le jour ? Ou est-ce que ce mode de fonctionnement est réservé à des équipes qui ont dépassé le stade de la nécessité de s'engager ?

Je réponds à Eric :

  • l'engagement de l'équipe porte sur l'objectif du sprint
  • le flux continu ne remet pas en question l'engagement sur cet objectif
  • l'objectif est défini lors de la planification de sprint
  • ce mode de fonctionnement en flux continu est compatible avec un engagement librement consenti
  • on ne revoit pas cet objectif tous les jours au moindre changement, évidemment, car il reste du mou par rapport à la capacité de l'équipe. Il est remis en question seulement si, de façon exceptionnelle, un événement imprévu survient (as usual).
  • on peut donc accepter de nouvelles stories pendant le sprint sans remettre en question l'objectif du sprint sur lequel on s'est engagé, tant que cela n'exclut pas une story indispensable pour l'attente de cet objectif


Lire aussi :

Les 6 activités de planification du sprint

La planification du sprint (en anglais Sprint Planning) est un événement Scrum qui se déroule à chaque début de sprint.

L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories.

Voici les activités qu'on y mène :

6 activités de planification du sprint

Voici un enchainement possible des activités :

L’équipe embrasse le contexte du sprint. Pour chaque story prête, en commençant par la première, l’équipe confirme avec le PO sa confiance pour la finir dans le sprint.

Pour faciliter la réalisation de la story, on prépare la tactique d’essaimage et on procède à l’identification des tâches.

Avec cette connaissance du travail à faire, l’équipe s’engage sur l’objectif du sprint. Le sprint est alors lancé et chacun, aligné sur l'objectif et la tactique collective, part réaliser une tâche.

Lectures en compléments :

Planifier pour réussir le sprint

En parcourant mon livre à la recherche du 6e D, je m'arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l'article près. Évidemment ce n'est pas ce que j'ai voulu. C'est un bug.

Je mène l'enquête et découvre rapidement que le bon titre du §9.1 est "Planifier pour réussir le sprint". D'ailleurs ce titre était déjà présent dans l'édition 3 et il apparaît dans les fichiers que j'ai conservés pour la fabrication de l'édition 4.

En fait, lors de ma dernière relecture juste avant mise en production, j'ai demandé à ce qu'on ajoute "Les" devant le titre du §9.2, par souci de cohérence. Voici un extrait du fichier markdown que j'ai utilisé pour communiquer mes retours de lecture :

Capture_d_e_cran_2017-01-31_a__06.23.36.png

L'éditrice de réalisation s'est trompée en l'appliquant au §9.1. Je ne m'en suis pas rendu compte avant la publication et je m'en excuse auprès de mes lecteurs. Je l'ajoute immédiatement aux quelques errata de cette édition. Voici ce que cela aurait dû donner :

Capture_d_e_cran_2017-01-31_a__05.52.59.png

J'en profite pour mettre en évidence le titre du § "C'est la story qui sprinte". Oui, l'idée que ce soit l'équipe qui sprinte pose problème, c'est pourquoi je préfère appliquer cette notion de sprint à la story.

Sprints synchronisés façon puzzle

Dans l'atelier Puzzle grand Scrum dont je parlais dans mon dernier billet, il y a donc 3 équipes qui concourent à la réalisation du puzzle. Le format du jeu pousse les équipes à se caler sur le même rythme.

C'est à dire que toutes les équipes commencent et finissent le sprint en même temps.

Avec les mises en œuvre de Scrum multi-équipes que j'accompagne, c'est ainsi que ça se passe, je pense notamment à Intel et Airbus.

Au cours de la quinzaine d'ateliers "puzzle" que j'ai animés, jamais personne n'a émis une proposition différente, des sprints décalés, qui serait par exemple : l'équipe bleue commence puis au bout du tiers du sprint, l'équipe verte commence, et aux deux tiers l'équipe rouge commence.

Dans mon livre édition 4, chapitre 21 "Développer des produits à plusieurs équipes", je ne présente pas d'alternative à la synchronisation des sprints pour du Scrum multi-équipes (§21.2.1). Je mets en avant l'intérêt de l'intégration fréquente entre les équipes pour cette approche.

Une discussion avec Pablo[1] lors du dernier Raid Agile m'a fait percevoir que cet argument n'était pas décisif : on peut aussi intégrer régulièrement si les sprints ne sont pas synchronisés.

Un intérêt plus évident est que cela facilite la tenue des événements du sprint[2]. Il est bien mis en évidence par l'atelier, en particulier pour l'organisation de la revue avec les parties prenantes. L'affinage multi-équipes cadencé est aussi facilité par la synchronisation des sprints.

Dans le chapitre 15 de Scrum et XP depuis les tranchées, Henrik Kniberg raconte qu'il avait d'abord expérimenté les sprints désynchronisés, avant d'être convaincu par Ken Schwaber de les synchroniser.

En plus des arguments évoqués, Kniberg évoque aussi la réorganisation des équipes, faisable en cas de sprints synchronisés, mais qu'il est probablement plus raisonnable de repousser en fin de release.

Notes

[1] Pablo, un partisan revendiqué des sprints multi-équipes désynchronisés.

[2] Dans mon livre, je fournis un tableau récapitulatif des événements du sprint à plusieurs équipes, page 277.

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...

Jour de fin de sprint

Résultat de mon enquête sur votre jour de la semaine pour finir un sprint.

Lire la suite...

Durée des sprints en 2015

Une majorité — relative — d'entre vous effectue des sprints de 2 semaines.

Lire la suite...

Les événements du sprint

Les événements du sprint

Bien sûr, il faut ajouter un événement à ceux de ce schéma : le scrum quotidien.

Lire la suite...

Engagement de sprint à l'usage des honnêtes gens

L'engagement est une valeur de Scrum. L'équipe est invitée à s'engager lors de la planification de sprint. Je constate que cette notion reste souvent mal comprise.

Voici quelques éclaircissements, qui s'appuient sur ma dernière lecture.

Lire la suite...

- page 1 de 6