La définition de prêt

La FAQ sur ce que veut dire prêt pour une story

La définition de fini est une pratique maintenant bien connue. La pratique symétrique, appelée définition de prêt, l’est beaucoup moins.

Pourtant, la définition de prêt commence à avoir une bonne visibilité :

Si elle est symétrique de la définition de fini :

  • la définition de fini permet au Product Owner de s’assurer que la story réalisée pendant le sprint par l’équipe respecte les critères attendus de finition,
  • la définition de prêt permet à l’équipe de s’assurer que la story préparée par le Product Owner respecte bien les critères attendus pour être commencée dans un sprint,

elle est encore plus difficile à bien appliquer.

Je suis en train de réfléchir à introduire du support à cette pratique dans iceScrum. Je vous livre quelques unes de mes réflexions, sous forme de FAQ.

Qui décide qu’une story est prête ou pas ?

C’est donc l’équipe qui décide si la story est prête.

Que se passe t-il si une story n’est pas prête ?

Une story non prête n’est pas acceptée dans un sprint qui commence. Autrement dit, on ne prend dans le sprint que des stories prêtes.

Que faire s’il n’y a pas de story prête, ou pas suffisamment au début du sprint ?

Toute l’équipe aide le Product Owner.

Quels sont les critères permettant à l’équipe de décider ?

  • Cela dépend du contexte, c’est à chaque équipe de se déterminer, comme pour la définition de fini.
  • Le point essentiel me paraît être que la story soit testable, c’est à dire qu’elle possède au moins un critère d’acceptation.

Est-ce que la définition de prêt s’applique aussi aux stories techniques ? Aux défauts ?

Oui la pratique s’applique. Avec des critères adaptés.

Qui fait en sorte qu’une story soit prête ?

C’est la responsabilité du Product Owner de préparer le backlog. Cependant il est normal qu’il se fasse aider par l’équipe. Lire ce billet pour plus d’infos.

A quel moment l’équipe évalue t-elle si une story est prête ?

  • En principe, cela se fait lors de la revue de backlog, quelques jours avant le début du prochain sprint. De mon point de vue, cette réunion a 2 objectifs : estimer les nouvelles stories et statuer sur les stories pour le prochain sprint. Le planning poker pratiqué pour estimer aide l’équipe à savoir si une nouvelle story est prête. L’examen des stories prioritaires et déjà estimées est ensuite pratiqué pour dire si elles sont prêtes.
  • Entre cette réunion et le début du sprint, il reste du temps pour améliorer des stories s’il n’y en avait pas suffisamment de prêtes.
  • Au début de la réunion de planification du sprint, lors de l’examen des stories candidates, l’évaluation est complétée.
  • Toujours dans cette réunion, quand elle fait la conception de la story et identifie les tâches, l’équipe peut considérer qu’une story n’est finalement pas prête.

Combien faut-il avoir de stories prêtes à l’avance ?

C’est du stock, il faut le limiter à l’équivalent d’un sprint, avec un peu de marge.

Et si je fais du Kanban ou du ScrumBan ?

Parfait. S’il n’y a pas de sprint, on va adapter la règle. Plutôt que dire :

une story non prête n’est pas acceptée dans un sprint qui commence

on va simplement mettre une colonne “Prête”, ce qui aura pour effet que seules les stories prêtes peuvent passer en cours.

Voir aussi :