Le sprint planning est un rituel clé, durant lequel, l'équipe scrum détermine l'objectif du sprint. En gestion de projet Scrum, ce sprint peut être annulé par le Product Owner, et ce, dans des cas rarissimes : objectif obsolète, changement de direction ou si les conditions du marché et/ou technologiques changent.
Dans cet article, nous verrons pourquoi et comment annuler un sprint.
Comment annuler un sprint et qui peut l’annuler ?
Commençons par planter le contexte de la méthodologie Scrum. Cette dernière fonctionne de manière itérative et incrémentale.
Une définition du sprint planning peut être : un évènement durant lequel l’équipe de développement va choisir les éléments les plus importants à développer. Ces éléments, une fois choisis, se retrouvent dans le sprint backlog.
Le but pour les experts est de développer l’ensemble des items qu'ils ont placés dans ce sprint backlog.
Afin de faciliter l’organisation de tous (clients, experts, Product Owner et Scrum Master), les durées de chaque évènement sont calculées dès le début du projet. Charge à l’équipe de développeurs d'optimiser son temps pour être la plus performante possible.
En sachant que l’approche est cyclique et que les phases sont redondantes, annuler un sprint planning bouleverse l’équilibre du projet. Raison pour laquelle cette éventualité doit être repoussée dans la quasi-totalité des cas.
La seule personne qui puisse prendre cette décision est le Product Owner (bien que les parties prenantes puissent orienter sa décision).
Quelles sont les raisons qui poussent à l’annulation d’un sprint ?
Malgré le fait que l’ensemble de l’équipe Scrum se prémunissent au maximum, un sprint peut être annulé lorsque :
- L’objectif est devenu obsolète
- L'entreprise change de direction
- Les conditions du marché et/ou technologiques évoluent
De ce fait, l’annulation est possible en fonction des circonstances, mais elle est rarement justifiable.
Les conséquences négatives de cette prise de décision sont multiples :
- Désengagement de la part de l’équipe Scrum
- Perte de temps
- Perte d’argent
Avec ces facteurs, la réussite du projet peut être compromise.
Quelles sont les mauvaises raisons d’annuler un sprint ?
Comme il y a des raisons qui peuvent justifier l'annulation d'un sprint, il y a de mauvaises raisons qui nécessitent de prendre les bonnes décisions.
Ainsi, il n'est pas recommandé d'annuler un sprint dans les cas suivants :
1) L'équipe ne pourra pas finir les items du sprint dans les délais
L’équipe qui se rend compte qu’elle ne pourra pas finir les items choisis dans le temps imparti au sprint backlog. Dans ce cas, l’équipe continue le sprint. À son échéance, elle doit placer à nouveau les items du sprint backlog dans le product backlog.
Mon conseil : Pour éviter que cette situation ne se reproduise, l’équipe devra prendre le temps de comprendre quelles sont les raisons du non-achèvement de leurs tâches dans le temps imparti lors de la rétrospective.
2) L'équipe a fini les items du sprint plutôt que prévu
Ici, l’équipe a peut-être surestimé le temps nécessaire au développement de chaque item. Aussi, il sera nécessaire d’y revenir en rétrospective.
Le réflexe de l’équipe est bien souvent d’avancer sur de nouveaux éléments du product backlog. Le risque est pris sur des besoins dont les priorités auront changé pour notre client. Il vaut probablement consolider la dette technique ou affiner le product backlog.
Mon conseil : Dans ces deux cas, il est possible d’avoir recours au Planning Poker. Cet outil ludique permet d’estimer, au plus juste, le temps requis au développement de chaque élément.
Que se passe-t-il après l’annulation d’un sprint ?
Dès lors qu’un sprint a été annulé par le Product Owner, tout le monde se regroupe lors d’une nouvelle rencontre de planification de sprint. Celle-ci génère une nouvelle perte de ressources.
Hormis le fait de stopper net la production, c’est tout le projet qui en est chamboulé.
En effet, toutes les cérémonies Scrum vont être déplacées
De plus, si tous les rituels sont décalés, il faudra revoir toute l’organisation avec les parties prenantes et s’assurer qu’elles soient disponibles sur ces nouveaux créneaux.
Il existe aussi une autre possibilité : Aller jusqu’à la date prévue du sprint planning.
Dans ce cas, comme nous l’avons évoqué plus haut, l’équipe d’experts va réaliser des actions d’amélioration technique sur le produit. Cette alternative n’est pas possible dans tous les projets.
Vous pouvez utiliser cette alternative lorsque :
- L’action va améliorer le MVP (produit minimum viable) tout en répondant aux nouveaux objectifs
- Vous avez constaté des soucis techniques qui doivent être résolus au plus vite
Notez que la cadence de l’équipe est rythmée en fonction des autres équipes. (C'est-à-dire que des membres de cette équipe peuvent faire partie d’autres équipes projet.)
Dans ce cas, il devient impossible de déplacer les rituels.
Pourquoi l’équipe Scrum ne parvient pas à traiter tout le product backlog ?
Tout simplement, car il n’est pas prévu pour !
En effet, le product backlog sert à lister tous les items qui peuvent être mis en place par l'équipe d’expert.
Ensuite, l’équipe de réalisation choisie les items les plus opportuns et les développe dans le sprint qui suit.
Le but de ce carnet de produit est simplement de recenser et prioriser les axes à développer. Il sert à construire la roadmap du produit, mais n’est en rien une planification.
L’engagement de l’équipe porte sur le développement de l’ensemble des items du sprint backlog.
En effet, les développeurs sélectionnent les tâches réalisables sur le sprint à venir. Bien entendu, ces derniers choisissent les items par priorisation du product backlog.
Une autre raison pour laquelle l’équipe ne suit pas à la lettre le product backlog : Il est amené à évoluer. C'est un artefact vivant !
Durant le développement des items par l’équipe de réalisation, le Product Owner continue donc son diagnostic des besoins. Et ce, pour plusieurs raisons :
- Le contexte de l’entreprise peut avoir évolué, de facto les besoins changent aussi
- Un nouveau besoin émerge suite aux retours-utilisateurs
- Le product owner et le client ont détecté une nouvelle opportunité à développer
Que faire pour éviter d’annuler un sprint ?
Pour éviter d’en arriver à annuler un sprint et toutes les déconvenues qui lui incombent, vous devez prendre en compte de nombreux facteurs avant de construire le product backlog.
Alors, comment pouvons-nous optimiser le product backlog ?
1) Établir la vision projet
C’est l’objectif du Product Owner. Ce dernier doit comprendre tous les tenants et les aboutissants du projet.
Ensuite, il doit faire en sorte que cette vision soit comprise et acceptée de tous. Cette étape est cruciale puisque tout le travail de développement se fera sur cette base.
2) Lister les parties prenantes
Ce sont toutes les personnes qui peuvent avoir une influence sur le projet.
Qu’elles aient un impact négatif ou positif, elles doivent être identifiées afin de prendre les bonnes décisions pour toutes les parties.
Notez qu’une partie prenante ne fait pas forcément partie du projet, mais que son influence peut changer la donne pour ce dernier.
3) Identifier les thèmes et les fonctionnalités afin de les regrouper
Cette phase survient à la suite des deux précédentes.
Plus les deux premières phases ont été travaillées, plus il sera simple de mettre en place ce fonctionnement.
L’équipe de développement pourra ainsi décider de qui fait quoi, en fonction des compétences et des préférences individuelles.
4) Déterminer la solution apportant le plus de valeur au client
Ici, l’équipe doit se poser les bonnes questions afin d’apporter le plus de valeur aux utilisateurs. Ce sont ces derniers à qui se destine le projet.
Faire des brainstormings suite à des retours-utilisateurs fait une grande différence pour combler leurs besoins.
5) Prioriser les actions
L’équipe Scrum doit nécessairement apporter ce qui a le plus de valeur ajoutée. Aussi bien pour s’assurer que le projet puisse être repris en cas d’arrêt, que pour affiner les fonctionnalités grâce aux feedbacks des usagers.
Conclusion
Lors d’un projet Scrum, il peut être envisageable d'annuler un sprint.
Néanmoins, cet évènement est et doit rester rarissime. Cela perturbe assurément l’équipe Scrum ainsi que toutes les autres parties prenantes du projet.
Le product owner est le seul à pouvoir prendre cette lourde décision. Bien entendu, cette décision survient après une discussion commune avec toute l’équipe et partage des points de vue de tous.
Il est primordial que le product owner responsabilise l’équipe de réalisation en lui indiquant le coût que cette annulation induit. Est-ce que cela en vaut réellement la peine ou est-il possible d’améliorer le travail déjà fournit ?
Toujours est-il que les développeurs doivent servir les objectifs du projet. Si les améliorations à apporter servent les nouveaux objectifs du sprint alors celui-ci devra continuer.
Dans le cas contraire, l’équipe Scrum et les autres parties prenantes devront s’organiser à nouveau en fonction des nouvelles dates prévues pour leurs cérémonies.
