Le mythe qu’un sprint backlog est fixe est faux !

Cet article a pour but de remettre certaines vérités en place comme celle-ci : le mythe qu’un sprint backlog est fixe est faux ! Je me permets d’écrire sur ce sujet car je vois trop d’équipes s’imposer cette règle peu importe la situation en la pensant juste.

Allons directement à la source

N’étant pas un fan avéré du Scrum bien que je lui trouve de nombreuses qualités, je suis surpris de voir que les forces du Scrum sont totalement oubliées par un certain nombre d’équipes.

Du coup, pour bien montrer qu’avoir un sprint backlog fixe est une légende, je vais directement piocher du contenu dans le Scrum Guide (en gros la définition du Scrum écrit par ses créateurs) traduit en français dans la rubrique sprint :

Pendant le Sprint: 

• L’objectif du sprint est fixe ; les changements qui le 
remettent en cause ne sont donc pas permis ; 

• Les objectifs de qualité sont maintenus ; ils ne sont 
jamais revus à la baisse ; et, 

• Le périmètre peut être clarifié et renégocié entre le 
Product Owner et l’équipe de développement selon ce que 
l’équipe Scrum apprend.

En effet, le Scrum conseille d’avancer en suivant un objectif clair et de s’y fixer mais le périmètre pour atteindre cet objectif peut-être variable. Ce n’est pas parce qu’on planifie un périmètre en début de sprint qu’on doit forcément bêtement le suivre à 100%.

C’est d’ailleurs une flexibilité très intéressante car elle existe mais impose un cadre qui évite d’aller vers l’anarchie. L’équipe ne perd pas le nord car même si le périmètre peut être revu en cours de sprint, les objectifs ne changent pas et restent clairs.

Le Scrumban pas juste un sprint backlog mouvant

En effet, certain décrivent le Scrumban comme une façon de faire un sprint où le périmètre sera flexible. En fait le Scrumban n’apporte pas cela en réalité car le Scrum autorise déjà cette façon de faire ; cette méthode permet surtout de travailler en flux tiré et non plus en flux poussé.

Article : Comprenons la différence entre le flux poussé et le flux tiré

Pourquoi c’est mieux un périmètre variable ?

L’agilité se veut être agile sur le périmètre donc cette idée que le sprint soit pas 100% fixe dans le contenu répond parfaitement à cette idée. Il n’est pas rare de voir des équipes qui se disent : « Ah mais ça, on ne peut pas faire en fait » ou « Je peux pas te dire faut creuser le sujet (utilisation de spike) ». J’ai déjà vu des équipes s’imposer de travailler sur le scope initial à 100% et finir par être perdues voire démotivées de ce type de rigidité…

Par contre le Scrum est un framework qui impose un « cadre léger » pour que le périmètre suive un objectif précis. C’est pas plus mal car si on peut jouer sur le périmètre, on est quand même dans un cadre qui évite d’avancer sans objectif partagé.

D’ailleurs si les objectifs doivent changer alors le Product Owner peut arrêter un Sprint comme le dit le Scrum Guide afin de repartir sur un nouvel objectif clair. Ce cadre permet d’éviter l’anarchie et la souplesse d’éviter la frustration.

Un Sprint peut être annulé avant son échéance. Seul le 
Product Owner a le pouvoir d'annuler le Sprint, bien qu'il 
ou elle puisse le faire sous l'influence des parties 
prenantes, de l'équipe de développement ou du Scrum Master.

Conclusion

Le mythe qu’un sprint backlog est fixe est faux ! Si les objectifs doivent être fixes du début jusqu’à la fin du sprint afin d’imposer un cadre léger, le périmètre est négociable dans l’équipe afin d’avoir un minimum de souplesse.