Cela fait quelques jours que vous travaillez sur un nouveau sprint, et vous vous rendez compte que si vous continuez ce sprint jusqu'au bout, ça ne servira à rien. Vous vous demandez au final si c'est possible d'annuler purement et simplement le sprint ?
Vous voilà bien embêté... Et je vous comprend. Faire du travail "pour rien", c'est révoltant.
Analysons ensemble dans cet article ce que nous dit le guide Scrum sur les annulations de sprint, afin de voir quels sont vos recours.
Peut-on mettre fin prématurément à un sprint ?
En effet, la lecture de la dernière version du guide Scrum ne laisse aucune place au doute :
"Un sprint peut être annulé si l'objectif de sprint devient obsolète. Seul le product owner a le pouvoir d'annuler le sprint".
Toutefois, cette version est moins prescriptive que le précédent Scrum guide :
"Un sprint serait annulé si l'objectif du sprint devient obsolète. Cela pourrait se produire si l'organisation change de direction ou si les conditions de marché ou celles technologiques changent.
En général, un sprint devrait être annulé s'il n'a plus de sens compte tenu des circonstances. Mais en raison de la courte durée de sprints, l'annulation est rarement justifiable".
Annuler un sprint doit rester de l'ordre de l'exceptionnel. C'est quelque chose qui reste traumatisant pour l'équipe, et qui peut à terme démotiver les membres.
4 raisons valides d'annuler un sprint
Le Scrum guide nous dit clairement qu'un sprint ne peut être annulé que si l'objectif de sprint devient obsolète.
Mais justement, qu'est-ce qui pourrait pousser un objectif à devenir caduque ? J'y vois 4 raisons :
- Un changement majeur de technologie.
- Une évolution soudaine du marché.
- Un besoin client qui n'est plus nécessaire.
- Un évènement extérieur qui invalide l'objectif de sprint.
Pourquoi ces 4 raisons sont valides ? Car elles modifient totalement l'objectif de sprint et l'approche que l'équipe de développement devrait avoir durant le sprint.
Les mauvaises raisons d'annulation d'un sprint
- L'équipe doit traiter des user stories du product backlog qui sont plus prioritaires que celles du sprint backlog.
Un sprint backlog est évolutif. S'il s'avère nécessaire de traiter en priorité ces user stories, elles devraient alors être ajoutées au sprint backlog en cours. Charge à l'équipe de voir si elle peut absorber cette surcharge de travail, où s'il faut "faire à la place de" quelque chose d'autre. - L'équipe découvre qu'elle n'est pas en mesure de finir le travail du sprint backlog dans les temps.
C'est une bonne chose. Cette information pourra être utilisée en rétrospective par l'équipe pour comprendre ce qui a pêché, et mieux prédire la charge de travail qu'elle peut produire en 1 sprint. - L'équipe de développement a terminé tous les éléments du sprint backlog en avance.
C'est une bonne nouvelle. Elle peut alors intégrer de nouveaux éléments au sprint backlog, tels que des bugs à corriger, ou d'autres user stories.
Qui peut annuler un sprint ?
L'annulation d'un sprint est de la responsabilité du product owner. Il est le seul à pouvoir la prononcer. L'équipe de développement et le scrum master peuvent toutefois essayer de l'influencer mais ils ne peuvent pas prendre la décision par eux-mêmes d'arrêter le sprint.
Comment annuler un sprint ?
Pour annuler un sprint, il faut respecter plusieurs conditions :
- L'annulation doit avoir lieu avant la fin de la timebox.
Autrement dit, avant la fin du sprint. - Le product owner doit prononcer l'annulation.
Il est le seul à en avoir le pouvoir. - L'objectif de sprint doit être obsolète.
L'équipe se retrouverait alors à faire du travail "pour rien". Ce n'est pas le meilleur moyen d'être efficace.
Une fois prononcée, l'annulation du sprint est immédiate.
Le Scrum guide version 2020 n'est pas du tout prescriptif sur le sujet : il laisse le champ libre à l'équipe Scrum pour s'organiser comme elle le souhaite.
Je vous recommande de ne pas enchaîner directement sur un nouveau sprint, afin de garder le même rythme et les mêmes créneaux horaires pour les différentes cérémonies.
Il peut être intéressant de réaliser une rétrospective sur l'annulation du sprint et ses causes, afin de comprendre ce qui s'est passé et voir ce qui pourrait être amélioré, avant de démarrer un nouveau sprint.
Doit-on commencer un nouveau sprint immédiatement après le sprint annulé ?
Personnellement, je vous conseille de prendre le temps d'analyser tout ça en rétrospective.
Faites également en sorte de ne pas perturber votre rythme de travail, la planification des cérémonies ou vos rituels.
Je vous conseille plutôt de planifier un mini sprint, par exemple pour corriger des bugs, estimer les éléments à intégrer au prochains print, préparer le prochain sprint backlog, traiter des sujets techniques, remanier le code, se former, etc...
Ce mini sprint est l'occasion de rembourser de la dette technique.
Que fait-on des items lorsqu'un sprint est annulé ?
Lorsqu'un sprint est annulé, la bonne pratique est de réaliser une mini-review du travail réalisé lors du sprint.
- Si le travail est terminé à 100%.
Il respecte la definition of done. Si ce travail a encore du sens, le product owner l'accepte et l'ajoute à l'incrément produit. - Si le travail n'est pas terminé.
Les éléments incomplets sont estimés à nouveau et remis dans le product backlog, s'ils ont toujours du sens. - Si les éléments du sprint backlog n'ont plus de sens.
Inutile de les rajouter au product backlog, on peut dans ce cas directement les supprimer.
Doit-on relancer un sprint planning après l'annulation d'un sprint ?
Faut-il relancer un sprint planning ou pas après l'annulation d'un sprint ? Bonne question. Et encore une fois, la réponse est : ça dépend.
L'ancienne version du scrum guide recommandait de relancer un sprint planning dès que la fin du sprint annulé, afin de démarrer un nouveau sprint.
Dans les faits, c'est plutôt complexe car ça revient à changer le rythme des sprints, à décaler toutes les réunions et cérémonies. Pas forcément très pratique.
C'est pour ça que le guide Scrum version 2020 est beaucoup plus "light" sur le sujet : on n'en parle tout simplement pas. Ce choix est entièrement laissé à l'équipe Scrum.
Personnellement, je recommande de ne pas bouger la cadence des sprints. Profitez donc du temsps jusqu'au prochain sprint pour réaliser des travaux d'amélioration technique sur le produit.
