Modifier des user stories en cours de sprint

modifier des user stories en cours de sprint
modifier des user stories en cours de sprint

Peut-on modifier des user stories en cours de sprint ? C’est la question que certains me posent encore, je vais donc y répondre par un article concret.

Vous pouvez aussi regarder la vidéo de la minute agile sur ce sujet :

Modifier des user stories en cours de sprint ?

Pendant quelques temps, une mauvaise pratique s’est mis en place dans de nombreuses équipes scrum : la definition of ready.

Beaucoup ont interprété cette pratique comme : « toute user story doit être ready en sprint planning et ne doit plus être modifiée »… Hors ce n’est pas en réalité l’objectif de la definition of ready.

Seul l’objectif du sprint est fixe !

Le scrum dit en réalité : « l’objectif du sprint est fixe, le scope est variable ».

Et en effet, en pensant qu’une user-story embarquée dans le sprint ne peut pas être modifiée tout au long de ce sprint, va à l’encontre du scrum ! Et ça amène même souvent les équipes à oublier l’élément clé du sprint : l’objectif du sprint.

Exemple pour comprendre !

L’équipe de développement s’aperçoit qu’il manque des éléments dans la user story pour que le besoin soit bien défini. Si cette user-story répond à l’objectif du sprint, il sera impératif que le product owner ou l’équipe aille chercher les informations manquantes ; à l’obtention de ces informations, la user story sera complétée.

Et l’équipe de développement qui veut livrer de la qualité va éviter de dire :

Pas grave, on fait ce qu’il y a écrit et on fera une une user story de rattrapage pour le prochain sprint !

Il est évident qu’il serait inconcevable de prendre une telle décision. Elle est responsable de la qualité des incréments, elle n’a tout simplement pas le droit d’agir ainsi.

Sans ce travail, l’équipe de développement ne pourrait plus atteindre l’objectif du sprint, ce qui amènerait le sprint à être annulé… Mais annuler le sprint alors qu’il est possible de trouver la solution serait un non-sens.

Il est donc évident que l’équipe de développement qui doit être focalisée sur l’objectif du sprint devra modifier la user story en question.

Un peu de culture agile

L’iron Triangle Agile rappelle d’ailleurs cette notion qui différencie les framework agiles comme scrum et les framework waterfall

agile iron triangle
agile iron triangle

En agile, le scope est variable ! Et ceci concerne le product backlog comme le sprint backlog.

Donc si vous vivez cette situation du « pas de modification de user story », rappelez juste ceci :

En scrum, l’objectif du sprint est fixe et le scope du sprint est variable ! La notion de scope variable est juste une base de l’agilité. 

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

1 Commentaire

  1. Bonjour
    On parle de modification d’une US en cours de sprint dans cette vidéo.
    Celà inclus donc la création d’une nouvelle US pendant le sprint qui sera rajouté au sprint en cours ,si elle ne remet pas en cause l’objectif du sprint, à l’initiative du PO en la partageant avec la DEV team qui renégociera le périmètre du sprint suite à cet ajout.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.