!! Spoiler alert !! Si vous pensez que mettre en place une DOR (Definition of Ready) va résoudre tous vos problèmes de rédaction des User Stories. J’ai le regret de vous annoncer qu’en lisant cet article, vous verrez que ce n’est pas du tout le cas.
Votre équipe vous répond en plein sprint planning les phrases suivantes :
_ « Non ! On ne le fera pas. On ne sait même pas où récupérer la donnée à afficher. »
_ « Un scroll infini dans un scroll infini ? Tu te rends compte de ce que tu demandes ? » (celle-ci est l’une de mes préférées)
Ou votre équipe vous fait remonter en rétrospective, alors que le sprint planning est prévu dans 1h :
_ « Les US prévues pour le prochain sprint, c’est franchement n’importe quoi !! »
_ « Ah ah, ton ticket xxxx il n’est même pas prêt. Tu penses vraiment que l’on va intégrer ce genre d’US dans le prochain sprint ? »
Des exemples comme ceux-là, il y en a plein. Mais si vous avez déjà entendu ou même, vous êtes déjà retrouvé dans l’une de ces situations, alors vous avez raté l’étape la plus importante dans le travail d’écriture de vos US, la discussion. Cette discussion est primordiale au sein de votre équipe, surtout lorsque l’on travaille sous une méthodologie Agile. Le point le plus important est de savoir quand cette discussion peut s’arrêter et quand votre US peut être considérée comme prête. Quel est ce moment où, en tant que PO, on est sûr d’avoir réalisé le minimum acceptable dans la rédaction des `US pour l’équipe Scrum et le prochain sprint planning ?
La réponse est toute simple et à la fois complexe, mais elle tient en 3 lettres : DOR. « Mais DOR qu’est-ce que c’est et en quoi ces 3 lettres vont-elles m’aider ? » me dites-vous. Je vais donc vous expliquer au fil de cet article, en quoi la DOR peut vous aider vous, ainsi que toute votre équipe Scrum à débuter vos sprints sereinement.
Comprendre la DOR
Celles et ceux qui ont lu le Scrum guide, se souviendront que la Definition of Ready (DOR) n’y est tout simplement pas mentionnée. Lorsque l’on se réfère au guide, le raffinement des US est réalisé lors du sprint planning. Il n’est pas nécessaire de raffiner complètement toutes les US que l’on va intégrer au sprint pour le débuter. Ce raffinement doit être réalisé au bon moment, et surtout quand cela a du sens. Avant, il est peut être trop tôt pour le faire.
« Comment dimensionner correctement le sprint backlog ? Surtout si en sprint planning on ne comprend même pas, à travers les US présentées, quel est le travail à réaliser ? Pourquoi réaliser ce travail ? Et quel est l’impact pour l’utilisateur final ? » me direz-vous. Le Scrum guide propose une solution toute faite, à savoir le Product Backlog Refinement. Toujours selon le Scrum guide, cette solution permet à l’équipe scrum de raffiner suffisamment les US de façon à ce qu’elles obtiennent un certain niveau de transparence. Et là vous me dites « Oui mais comment définir ce niveau de transparence tant recherché ? ». C’est ainsi que la DOR peut prendre tout son sens. Mais attention à la façon dont vous allez l’utiliser.
La DOR n’est pas une checklist que l’on parcourt afin de confirmer que notre user story est prête à intégrer un sprint.
Souvent, lorsque l’on réalise une recherche sur la DOR, l’explication donnée est que celle-ci prend la forme d’une checklist que l’on va compléter avec l’équipe. Cette dernière permettra de valider chaque US avant qu’elle ne soit considérée comme prête. Tout cela est complètement absurde. La DOR n’est pas une checklist que l’on parcourt afin de confirmer que notre user story est prête à intégrer un sprint. Et j’insiste fortement dessus. D’ailleurs, à devenir aussi restrictif, où passe donc cette prétendue agilité ?
Il faut savoir qu’une DOR n’est nullement obligatoire. A chaque équipe sa façon de travailler et donc de raffiner une US. Si au sein de votre scrum team vous n’avez aucun problème de compréhension ou de doutes sur les US présentées en sprint planning, alors le meilleur conseil que je peux vous donner, est de ne pas mettre en place de DOR, car elle vous est pour le moment inutile.
Pour comprendre la DOR, il faut d’abord comprendre pourquoi on la met en place. Ce qui mène à la mise en place d’une Definition of Ready, c’est le manque de discussion au sein de l’équipe et/ou le manque de confiance notamment lors de la rédaction et du raffinement des US. Pour aller plus loin, c’est lorsque l’équipe n’est pas en accord sur le niveau de transparence des US qui peuvent intégrer un sprint. Cela peut être le résultat de beaucoup de choses. Mais nul besoin de pointer du doigt quiconque car travailler en Scrum c’est travailler en équipe. Pour y remédier, on peut mettre en place une DOR, non sans avoir pris le temps de vraiment en discuter.
Definition of Ready ou bon sens ?
Du bon sens ? Oui car s’est tout simplement ce qu’est pour moi une DOR. Une definition of Ready est une ligne directrice qui doit, non pas définir que votre US est prête, mais vous aider à ressentir lorsque votre travail de rédaction en tant que PO est suffisamment avancé pour être présenté en sprint planning.
Éviter les listes à rallonge et n’écrivez que ce qui fait sens. Oubliez tout ce qui définit qu’une US doit avoir un titre, une description, des critères d’acceptation et j’en passe. Cela relève du bon sens. Il est préférable de travailler le template utilisé pour rédiger vos US que de le spécifier inutilement dans une DOR. J’ai d’ailleurs écrit un article sur le sujet si vous avez un peu de temps pour une petite lecture : La User Story : Comment bien la rédiger ?
Quelques exemples de DOR
Prenons l’exemple suivant. Vous êtes PO et travaillez sur un produit plutôt complexe impliquant des APIs internes et externes. Les US portant sur des APIs sont souvent refusées par votre équipe en sprint planning car elles sont trop incomplètes pour être estimables. Afin que votre équipe puisse comprendre et estimer le travail à réaliser, ils ont besoin de certaines informations qui manque cruellement à vos US. `Suite à une rétrospective, vous et votre équipe décidez de mettre en place une DOR à travers un atelier dont voici un extrait du résultat final.
Definition of Ready – TEAM FRUIT A PAIN
- API externe
- Clé publique
- Lien vers l’API
- Contrat d’interface
- Documentation(s) sur l’API (lien(s) et/ou fichier(s))
- API interne
- Lien vers l’API
- Lien vers la documentation de l’API
- Création d’une API
- Lien vers la base de donnée
- Table(s) & colonne(s) concernées
- Gateway
- Opération(s) autorisée(s) (POST / PUT / GET / DELETE)
- Lien vers une tâche de documentation
- Modification d’une API
- […]
Prenons maintenant l’exemple d’une autre équipe. Le nouveau PO, habitué à travailler sur des sujets plutôt backend éprouve quelques difficultés sur les tickets liés à la modification des différents Design Systems. Au cours d’un Product Backlog Refinement, il a demandé à ce que l’équipe se réunisse afin d’établir une DOR. De façon à être plus autonome et ne plus mobiliser des membres de l’équipe sans que cela ai du sens. Suite à l’atelier, voici un extrait de la DOR qu’ils ont établi.
Definition of Ready – TEAM Christophine
- Design System
- Bibliothèque
- Id de l’élément
- Lien Figma
- Lien vers une tâche de documentation
- Page de contenu
- Lien figma
- Textes (JSON)
- Images (Zip)
- Événements (analytics)
- […]
- […]
Ma User Story est prête
La DOR doit être lisible et compréhensible par toute l’équipe. Outre les informations dites classiques d’une US, l’équipe Scrum, grâce à cette ligne directrice peut maintenant mieux travailler et discuter. La finalité, l’équipe en sprint planning est dorénavant capable de comprendre, raffiner si nécessaire et estimer le travail à réaliser.
Avec une bonne DOR, débuter vos sprints deviendra un jeu d’enfant et votre équipe ne refusera plus de User Stories en sprint planning. Quelques rappels me semblent toutefois importants :
- La DOR n’est pas une checklist et ne le sera jamais.
- Pensez à revoir votre DOR autant que nécessaire. La rétrospective est d’ailleurs le meilleur moment pour le faire.
- Avec l’augmentation de la maturité de votre équipe, n’hésitez pas à supprimer des éléments de votre DOR qui ne font plus sens, la discussion est la clé.
N’hésitez pas à me dire et à me partager ce qu’est pour vous la DOR et comment vous la mettez en place (ou pas).
Agilement vôtre,
Transparence, Inspection, Adaptation,
Jonathan
