Écrit par Charlie, Scrum Master

Certaines tâches sont plus compliquées que prévues. Kim, Swann, Clarence, Noa et Claude, les développeurs, terminent de coder quelques Items le dernier jour du Sprint, sans avoir le temps de faire une « code review » ou encore les tests nécessaires de Louison, la QA, qui permettraient de passer les items à « done ». Ils se posent la question, avant de me voir avec Morgan (le PO), « Que faire des items qui ne sont pas « done » sans que cela impacte la production ? » 

Pendant la pause-café, avant de commencer la journée, l’équipe de développement parle avec Morgan pour proposer des alternatives, des solutions que d’autres équipes de l’entreprise utilisent.

Kim – “Ce n’est pas si grave ! On peut mettre les items en cours dans le prochain sprint. Il ne reste pas grand-chose à faire”.

Pour Claude, cela n’est pas nécessaire de consulter Morgan sur ce sujet. Elle pense comme Kim, la priorité n’a pas changé, il n’est donc pas utile de parler du sujet au PO, et passer directement les items dans le prochain sprint. 

Clarence – Les items sont presque finis, donc on peut les passer à « done » et avoir les points des US dans le Sprint, ensuite créer quelques bugs pour finir ce qu’il reste à faire.

Swann – On peut faire un « Split ». On prend un item et on peut le diviser en deux. On garde les points de ce qu’on a déjà fait pendant le sprint et on met le reste des points dans le nouvel item pour le reste à faire.

Morgan – Je comprends votre frustration de ne pas avoir  fini les items, nous allons faire une réunion avec Charlie, notre Scrum Master, pour trouver la meilleure solution.

Pendant la réunion, Morgan explique :

 Le fait de passer automatiquement les items sans réestimation, n‘est pas la bonne solution. Je m’explique :

  • Les items non finis de ce sprint, ne sont pas en adéquation avec le «sprint goal» du futur sprint. Ceci entraînera donc un souci de transparence vis-à-vis des parties prenantes sur ce qui sera réalisé lors du prochain sprint.
  • De plus, ajouter des items sur le futur sprint, risque de rendre difficile de finir le sprint car nous aurons bien plus de travail que prévu mais le sprint ne sera pas prolongé pour autant. Nous risquons donc d’accumuler de plus en plus de retard, et d’avoir un cercle vicieux de sprints incomplets.
  • Ensuite, la vélocité de l’équipe ne sera pas représentative de la réalité, car une partie des items est déjà faite et le reste à faire ne correspond donc plus à l’estimation initiale.
  • Tous ces points entraîneront une baisse de motivation de l’équipe, liée à la fatigue et à la frustration des sprints qui ne sont pas finis.
  • De plus, il y aura également une frustration et une perte de confiance de la part des parties prenantes qui n’auront pas les items attendus à la fin des sprints. 

Pour la proposition de passer les items à « done », cela n’est pas en adéquation avec le framework Scrum car c’est seulement les items qui respectent ce qui est décrit dans la « definition of done » qui peuvent être considérés comme terminés. Si on fait ça, notre « definition of done » n’est pas respectée.

La solution de diviser un item et son estimation en deux n’est pas non plus une bonne solution car : 

  • La vélocité du sprint ne reflète pas la réalité de ce qui a été réalisé.
  • De plus, le « second » item créé dans le but de finaliser l’item initial, n’aura pas la bonne estimation également, ce qui faussera la vélocité du sprint dans lequel elle sera développée.

Ils me demandent : « Au vu de tout cela, Charlie pourrais-tu nous donner ton point de vue, tes recommandations et/ou suggestions vis-à-vis de cette situation s’il te plaît ?

Post-It, Tablón De Anuncios, Notas Adhesivas, Lista

– Je peux vous donner mon point de vue sur ce sujet, ainsi que mes recommandations afin de continuer à travailler en Scrum. Mais, il est de votre responsabilité, en tant qu’équipe autonome de développement, de décider de la méthode qui vous est la plus appropriée.

Il est essentiel de suivre ce principe : « Les items non terminés doivent retourner dans le « Product Backlog » pour être réestimés plus tard »

C’est pour cela qu’il faut vérifier que la « DoD » soit claire dans ce qui fait dans item qu’il est terminé. Ceci doit être définie par l’équipe de développement lors de la sprint retrospective. Si elle n’est pas adaptée à l’équipe, elle doit être revue et redéfinie dès la prochaine rétrospective. 

La « definition of done » comprends toutes les étapes que doivent passés les items afin d’être considéré comme terminés. Elle doit être claire et transparente pour tous, que ce soit la scrum team ou les parties prenantes. Les items ne respectant pas la «DoD » ne peuvent pas être présentés lors de la sprint review, car ils ne sont pas « finis ». 

La «DoD» peut inclure tout ce qui est jugé nécessaire par l’équipe de développement et être de plus en plus complète au fur et à mesure de son « improvement ».

Par conséquent, nous verrons lors de la prochaine rétrospective, ce qui a causé ce retard et ce que nous aurions pu faire pour pouvoir finir le sprint. »

Noa – Donc pour conclure, nous remettons les items non terminés dans le product backlog pour ré-estimation avant ré-injection dans un futur sprint. Merci Charlie pour ton retour.

Plus tard ce jour-là, lors de la rétrospective, la scrum team se réunit afin de faire un point sur le sprint qui vient de se finir.