La définition de Prêt
Auteur : Serge Beaumont
Source : The Definition of READY
Date : 19/06/2009
Traducteur : Fabrice Aimetti
Date : 08/07/2009
Traduction :
Hier, j’ai participé à la conférence "Integrating Agile" durant laquelle j’ai fourni certains éléments de réponse concernant une problématique que je considère comme étant le "Grand Trou Noir" de Scrum : le rôle du Product Owner. Suite à l’échange qui a eu lieu, je souhaitais écrire un billet sur le sujet et "éclaircir" un peu le trou noir... :)
La Définition de Prêt
J’ai donné des cours de CSM (Certified Scrum Trainer) avec Jeff Sutherland, et il y a à peu près 6 mois, il a ajouté dans ses supports de cours des références à ce qu’il nomme "le modèle dynamique de Scrum". La caractéristique principale était l’ajout d’un état PRÊT à l’opposé de l’état TERMINÉ. Ici, l’idée est que l’équipe a besoin de se trouver dans une situation stable et connue, pour être capable d’accomplir son travail correctement. Cela a immédiatement trouver un écho en moi : j’ai vu tellement d’équipes mises en difficulté, que mettre en œuvre l’état PRÊT me semblait effectivement le but à atteindre. Mais l’était-il réellement et comment l’atteindre ? Je pense pouvoir aujourd’hui bien répondre à ces questions.
"Extrait de mes supports de cours Scrum illustrant le concept..."
Dans une équipe auto-organisée, montrer clairement la cible à atteindre est très important : l’auto-organisation n’existe pas si vous n’avez rien à organiser. L’état PRÊT empêche l’équipe d’être mise en difficulté en lui garantissant que les pré-requis nécessaires à la bonne exécution d’un Sprint ont bien été remplis.
Définir PRÊT
Le mode de définition de PRÊT est identique à celui de TERMINÉ à quelques différences près. Alors que dans la Définition de TERMINÉ le "fournisseur" est l’Équipe et le "client" est le Product Owner, il en va tout autrement avec la __Définition de PRÊT : l’Équipe est le "client" et le Product Owner est le "fournisseur". Même si je détaillerai la définition de PRÊT plus tard, on peut déjà dire qu’être dans l’état PRÊT revient à ce que l’équipe déclare : "Ah, nous y sommes !".
Même si l’on peut ajouter n’importe quel pré-requis à la Définition de PRÊT, le besoin de disposer d’un bon backlog passe devant toutes les autres considérations ; vous devez donc travailler sur deux éléments : préparation des User Stories et préparation du Backlog.
Quand une User Story est-elle PRÊTE ?
J’ai constaté qu’une User Story est prête lorsque vous avez répondu à 3 questions : Pourquoi ? Quoi ? et Comment ?, qu’elle a été estimée et qu’elle est suffisamment petite.
- Pourquoi ? Qu’essaye d’atteindre les parties prenantes ? Quels sont leurs objectifs ? Quel est le contexte métier ? Quelle est la Valeur Quantitative ?
- Quoi ? Quelle est la Vision de la Cible ? Quel est le résultat final de la user story ?
- Comment ? Quelle est la Stratégie d’Implémentation ? Quel est le coût associé (story points) ? La story est-elle suffisamment petite (story points vs vélocité de l’équipe) ?
- Notez bien qu’en répondant à ces questions, je n’en déduis pas que vous devez tout documenter. Encore une fois, c’est l’équipe qui sait ce dont elle a besoin. Si le dos d’une nappe suffit, alors allez y. Si l’équipe demande plus, alors donnez lui. Notez que le niveau de détail nécessaire doit être déterminé par user story. Certaines user stories métiers sont classiques comme d’habitude, et il peut suffire de dire : "Je veux l’une de ces choses, mais cette fois en vert". Par contre, d’autres user stories pourraient être moins évidentes, par exemple, si elles sont liées à un nouveau processus dans le service de soins intensifs d’un hôpital. Vous avez peut-être besoin d’un peu plus dans ce cas là... :-)
J’utilise le terme "stratégie d’implémentation" pour clarifier un peu plus le besoin de détail désiré. Spécifié totalement le Comment ? vous ramènerez au modèle de la cascade, mais vous ne pourrez pas effectuer une estimation par points si l’équipe n’a pas une première idée de la manière dont elle va aborder la user story. Par conséquent, vous allez aussi loin que nécessaire pour spécifier l’implémentation et permettre une estimation par points. Notez qu’il s’agit d’un effet secondaire inhérent aux sessions de planning poker, donc le plus facile est de capturer le besoin tout au long de l’estimation. Et je vous conseille vraiment de le faire. J’ai trop souvent constaté que l’équipe se reposait la question de savoir pourquoi elle avait estimé 5 points pour telle user story, 2 jours à peine après la session de planning poker... :-)
Finalement, une User Story est PRÊTE si l’équipe peut l’implémenter et si le Product Owner peut la prioriser.
Quand le Backlog est-il PRÊT ?
Le backlog est PRÊT lorsqu’un ensemble de User Stories couvrant de 1,5 à 2 Sprints dans le haut du backlog sont PRÊTES, que ces user stories sont suffisamment petites pour permettre de les répartir dans l’équipe.
Pour finir, suivez ce précepte :
Ne conservez rien dans l’état non PRÊT dans votre Sprint et ne laissez rien en sortir qui ne soit dans l’état TERMINÉ.
Bien, maintenant que nous savons définir l’état PRÊT, je vous raconterai dans un prochain billet comment atteindre cet état...
