La pratique "Définition de prêt pour une story"

La définition de fini est une pratique maintenant bien connue. La pratique symétrique, la 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 ?
A quel moment l'équipe évalue t-elle si une story est prête ?
  • En principe, cela se fait lors de la revue de backog, 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.

Commentaires

1. Le dimanche 19 février 2012, 15:14 par Vicnet

"Prete = au moins testable"
Oui, mais si ma notion de fini ne comporte pas le fait d'être testable.

En fait dans la définition de fini, ce n'est pas testable mais testée qui convient. Ok, c'est une aberration mais c'est juste pour montrer qu'à mon avis, le critère min pour être prete est le fait qu'elle puisse répondre aux critères de fini à la fin du sprint, donc en effet testable, non ? Effectivement une cohérence entre les 2 définitions est nécessaire.

J'utilise beaucoup la notion de prete, mais avant ce billet, je n'avais pas penser à la formaliser comme je l'ai fait avec la notion de fini (qui est affichée à coté du tableau scrum).
Merci
PS: pourquoi utiliser le terme de story plutot que le chouette terme d'histoire en fr ?

C'est une longue histoire... qui a commencé en 2006 avec user story (http://www.aubryconseil.com/post/2006/04/13/7-user-stories et http://www.aubryconseil.com/post/2006/10/16/106-des-histoires-d-utilisateur), s'est poursuivie en 2007 avec histoires (http://www.aubryconseil.com/post/2007/04/09/203-user-stories-et-use-cases) pour finalement revenir à story, terme que j'utilise dans mon livre.
2. Le lundi 20 février 2012, 13:24 par julien

Dans un projet BDD une bonne notion de prêt est la validation des scenarios au format gherkin (cucumber, jbehave ...) de la story.

3. Le vendredi 24 février 2012, 10:39 par Benoit Gantaume

Claude,
Je trouve l'idée très intéressante et à défaut d'une définition claire, j'ai par contre un critère d'une story 'non-prête' que j'utilise souvent: la présence d'une dépendance externe non résolue en début de sprint.
ex: je dois livrer cette page, mais je n'ai pas les créas.
ou bien: je dépend de telle API que je n'ai pas encore reçue.
Dans ce type de cas, j'essaie de repousser la story au sprint suivant, sinon on arrive souvent à des situations de blocage. S'il faut vraiment ajouter la story au sprint, le PO s'engage sur la mise à disposition des ressources nécessaires à temps, et accepte que la story ne soit pas livrée sinon.
Qu'en penses-tu?
Comment gères-tu les dépendances externes à l'équipe?

  1. ++

Benoit