Definition of ready : L’essentiel à savoir !
La definition of ready c’est un peu le concept que tous les product owners doivent connaître alors qu’il ne fait même pas partie du scrum guide.
Dans ce post je vous explique :
- Ce que vous devez savoir sur la definition of ready
- Pourquoi vous devez vous en soucier
- Comment la définir ?
- Les controverses à son sujet.
Le concept de definition of ready :
- Le concept de definition of ready s’applique uniquement aux users stories
- Ne l’appliquez pas aux bugs ou aux sous-tâches ou encore moins aux épics (contactez moi si vous voulez des détails).
- La definition of ready est un contrat entre le PO et les développeurs
- C’est un rappel des éléments nécessaires à inclure dans une user story.
- Sans ces éléments, la US n’est pas considérée prête (READY) pour être développée.
Par exemple dans ma team, pour que l’US soit “ready”, elle doit contenir :
- Un titre
- Une courte description
- Des règles métiers
- Des spécifications techniques
- Les critères d’acceptation
- Un objectif mesurable (KPI…)
- Des maquettes (si besoin…)
- Et surtout, une estimation
S’il manque un des critères, l’US ne passe pas en TO DO et ne peut pas être planifiée dans le sprint.
A retenir :
- La Definition of ready est parfois appelée sous l’acronyme DoR
- Le scrum guide parle du concept de backlog refinement, qui est peu ou prou une autre manière de définir le concept de Definition of ready
Pourquoi vous devez vous en soucier ?
Elle permet de rédiger une US dans les règles de l’art
Cela risque d’en faire bondir certains mais si la Definition of ready est si importante c’est parce qu’elle définit carrément comment rédiger une user story dans votre équipe.
En effet, on peut débattre pendant des heures sur ce qu’est une User Story ou comment bien l’écrire.
- Certains suivent le framework INVEST à la lettre
- D’autres comme moi sont un peu plus souple car je trouve ce Framework trop rigide (j’en parle ici)
La vérité c’est qu’il y a plusieurs façons d’écrire une US selon les POs et surtout selon les équipes.
En revanche, peu importe comment vous l’écrivez, le seul objectif c’est qu’elle soit comprise par votre “Dev team”.
En ce sens, la DoR définit les critères que vos devs requiert pour comprendre vos US.
Un format d’US reconnaissable
En gros, voici l’idée à retenir pour comprendre la DoR.
En appliquant une Definition of ready avec votre équipe, vous leur assurez un format D’US clair et reconnaissable.
A chaque fois que vous présentez une US à vos Devs, il n’y a plus de surprises.
- Ils / elles savent à quoi s’attendre
- Ils la comprennent directement
En gros une Definition of ready, c’est un peu la signature de votre team.
Selon les critères que vous avez admis de toujours indiquer dans votre DoR, on reconnaît vos US à celles d’un autre PO.
Un gain de temps considérable
La DoR permet de vous faire gagner du temps dans vos backlogs grooming car à la longue, c’est plus facile à lire et plus rapide à comprendre pour les initiés.
Par ailleurs, avec une DoR bien définie, vous avez un template US répétable à l’infini.
Lors de la rédaction d’une US, vous avez déjà la structure, vous n’avez qu’à remplir les cases.
A retenir
Avec une DoR, toutes vos US sont formatées de la même façon. C’est un véritable process de rédaction.
Comment établir la definition of ready ?
Une Definition of Ready se définit dès le démarrage d’une mission avec une nouvelle équipe.
Si vous êtes un PO junior.
Organisez une petite conversation tout de suite avec votre équipe et récoltez leurs besoins en terme de spécifications.
Les devs ont toujours plein d’avis pour vous indiquer ce que vous devez écrire.
Voici les 3 questions clés
- Quel est le format d’US que vous utilisez jusqu’ici
- Qu’est ce qui marche ?
- Qu’est ce qui manque ?
Rappelez leur que le but ultime est que la DoR doit leur permettre de pouvoir démarrer une tâche en ayant le moins de questions de compréhensions possibles.
Mettez vous d’accord sur les critères clés à rappeler dans une US avant de la déclarer READY
Si vous êtes un PO sénior.
Si vous avez de la bouteille, il se peut que vous avez déjà une idée précise de votre DoR.
Montrez quelques exemples à votre nouvelle équipe et posez leur ces questions :
- Comprenez vous ces formats d’US ?
- Qu’est ce qu’ils vous manquent ?
- Voyez-vous une amélioration par rapport à vos précédentes US.
Les réponses vont aussi dépendre de la maturité de votre équipe et de leur expérience avec l’agilité.
Soyez souple et trouvez un terrain d’entente pour commencer.
A retenir :
La definition of ready évolue souvent dans le temps.
Au fur et à mesure des sprints, on s’aperçoit dans les backlogs grooming et les rétrospectives si la rédaction des US a posée des problèmes de compréhension au démarrage des tâches.
C’est le moment pour affiner votre DoR et de l’adapter à votre team.
Les controverses à propos du DoR
Comme le DoR touche à la rédaction des US et ne figure pas dans le scrum guide, il y a forcément débat.
1. La definition of Ready est anti agile :
Le gros argument pour dire qu’un DoR n’est pas agile c’est de dire que cela créé des retards ou des ralentissements.
En détail, certains pensent qu’une Definition of Ready demande aux PO d’être particulièrement consciencieux dans la rédaction d’une US, ce qui demande par définition de passer plus de temps à respecter la liste des critères définies.
Conséquence, cela ajoute du temps à la phase de conception et de spécifications et fait perdre de la vélocité.
Dans certains cas extrêmes, j’ai entendu dire des développeurs se plaindre qu’ils n’avaient pas de tâches à faire car les US n’arrivaient pas assez vite.
Mon avis :
Si vous êtes dans ce cas, il y a effectivement un problème mais je ne pense pas que ca soit la DoR en elle même.
- Il se peut que votre liste de critères pour votre DoR soit trop intense. Il faut peut être en parler et la réduire.
- Le problème est peut être aussi que vous n’avez pas bien découpé vos US.
Peu importe votre definition of Ready, vos US doivent rester simple et le plus court possible.
On parle d’une US pas d’un cahier des charges, il faut pas déconner… ca ne prend pas autant de temps que cela.
Au contraire, comme je l’ai expliqué plus haut, un DoR vous donne un format précis à respecter.
Vous devez être capable de sortir des US rapidement et les présenter.
- Enfin, une definition of ready permet d’éviter toutes incompréhensions aux tâches des devs.
- Cela apporte de la rigueur qui permet de développer plus vite et d’éviter des bugs ou des oublis dans l’US.
Ceux qui connaissent savent que c’est hyper chronophage à rattraper.
2. On peut planifier une US not Ready
Alors, j’ai vu et lu ici et là, que l’on pouvait planifier une US dans un sprint et la mettre dans la colonne TO DO alors que le DoR n’était pas encore respectée.
L’idée principale est de se dire
“On doit absolument faire cette US dans le prochain sprint, on la passe et on la rédigera correctement en cours de sprint, c’est plus agile”.
Mon avis :
Mouais… je suis moyen chaud pour cette technique.
La raison est simple : Dans ma definition of Ready, le chiffrage (ou estimation) de mon US est un critère absolument obligatoire.
En gros, tant que l’US n’est pas chiffrée, elle ne peut pas être planifiée.
- Cela me permet de sizer mon sprint avec une dose d’effort qui est théoriquement possible d’être réalisée en fonction de la vélocité de mon équipe (j’en parle dans cet article : Le sprint planning)
- Si je commence à mettre des US non chiffrées dans le sprint, il peut y avoir des mauvaises surprises à l’arrivée (retards…).
- Cela peut donner l’impression également d’avoir charger la mule et de compter sur la bonne volonté des développeurs.
A mon avis, ce genre de pratique en scrum, ça passe une fois avec l’équipe mais pas 2.
Vos devs vont vous prendre pour un PO qui ne fait pas les efforts préparatoires pour spécifier et planifier correctement et vous allez en entendre parler.
A ce jeu là, mieux vaut passer en mode Kanban et abandonner le scrum.
Morale de l’histoire
La definition of ready n’a pas le même effet de buzzword que sa cousine la definition of done (DoD) mais elle est tout aussi importante que celle-ci (voir même plus du point de vue d’un PO).
C’est un concept simple à comprendre mais qui demande d’être pensé et utilisé différemment en fonction du contexte dans lequel évolue chaque product owner.
C’est un outil puissant pour fluidifier votre workflow et le travail d’équipe.
Super article !
mais …please ! Faut arréter les GIFS dans vos posts ! C’est très pertubant visuellement parlant ! Très stroboscopique !