Les conditions de réalisation

Une story est prête à prendre le départ du sprint si son comportement attendu (conditions d'acceptation) et la qualité requise (critères de finition) sont suffisamment connus de l'équipe. Un autre volet essentiel pour s'assurer de la capacité de l'équipe à développer la story pendant le sprint porte sur les conditions de réalisation.

Les 3 composants d'une story

Qu'y a t-il dans la définition de prêt d'une story ?

C'est dépendant du contexte et c'est à chaque équipe d'établir sa propre définition de prêt. En général, on y trouve une référence à ce qui permettra de dire que la story est finie pendant le sprint, ce qu'on appelle sa définition de fini, qui comprend 2 parties :

  • les conditions d'acceptation,
  • les critères de finition, autrement dit ce qui permet de garantir que cette story ne crée pas de dette technique supplémentaire.

En gros pour qu'une story soit prête, il faut que l'équipe ait une solide connaissance de comment elle sera finie, lui permettant de prendre le départ du sprint sans trop de risque.

C'est déjà pas mal pour contribuer à la confiance de l'équipe à réaliser une story en un sprint. Ce n'est pas suffisant, il faut aussi vérifier les conditions de réalisation.

Est-ce que l'équipe est capable de commencer et de développer cette story compte tenu de ses moyens ?

Il peut y avoir un certain nombre de conditions à vérifier pour cela. Les conditions de réalisation portent, par exemple, sur :

  • la dépendance forte sur un membre de l'équipe, seul à pouvoir réaliser une tâche nécessaire pour développer la story,
  • plus embêtant, la dépendance sur une partie prenante experte (PPE), qui n'est pas dans l'équipe et dont la participation est indispensable pour finir la story,
  • un composant matériel ou logiciel ou un outil requis pour développer la story.

Ces conditions sont spécifiques d'une story. On peut aussi avoir une règle générique, par exemple sur le nombre de points de la story. Cela permet de s'assurer que la story n'est pas trop grosse.

La décision de déclarer une story prête, en la plaçant dans le bac de départ, se fait de façon collective, lors d'une conversation avec le PO.

Commentaires

1. Le lundi 20 janvier 2014, 09:51 par Omar BENHAMID

+1 ! La qualité des story au départ est clé pour le bon fonctionnement de l'itération et du projet agile.

Ce que vous dites me rappelle les critères INVEST, notemment le *Estimable* qui renvoi en réalité au fait que "l'equipe voit comment réaliser la story" et le *Sized properly* qui indique que la story doit avoir une taille acceptable.

J'avais fait un post sur INVEST sur mon blog ici : http://obenhamid.me/2014/01/les-6-p...

La discussion continue ailleurs

1. Le lundi 20 janvier 2014, 09:45 par Anonymous blog

INVEST – Les 6 piliers d’une bonne User Story scrum | Le 10e

(…) Une user story est censée être un sujet de discussions et non pas une description détaillée d’une fonction. Il n ‘y a pas de mal à ce que une story soit au départ trops générique (…)