Présentation de l'essentiel sur le DoR - Definition Of Ready. Contenu riche en informations claires et faciles à assimiler provenant directement d'expériences vécues et de situations réelles.

1. Notion de “Definition Of Ready”
L’essentiel sur le DoR
WeAgile Morocco
Badr Hadria
Coach agile

2. C’est quoi
C’est une simple “check-list” ou “liste d’activités” à vérifier rigoureusement avant de déclarer qu’une
story est vraiment “prête” (on parle aussi du “Ready Ready”) pour la réalisation et la livraison dans le
cadre d’un sprint.
Ou encore, une liste de pré-conditions à vérifier avant d’embarquer une story dans le backlog du sprint.
C’est un actif crucial et très important pour une équipe qui délivre en agile.
Il n’est pas encore cité officiellement dans le “Scrum guide” (qui parle que du “Backlog refinement”)
2

3. Pourquoi
Favoriser la transparence
Responsabiliser le PO et l’équipe de développement par rapport au niveau de maturité des
exigences/User Stories avant de les réaliser et les livrer à l’état “DONE” durant un sprint.
Identifier en amont les dépendances à fort impact.
Identifier en amont les points nécessitants des sessions d’affinage, et les accepter.
Disposer de PBIs* clairs, prêts, réalisables et testables rapidement et efficacement durant un sprint.
Réduire la pression sur l’équipe de développement.
*PBI : Product Backlog Items
3

4. Pour qui
Essentiellement pour l’équipe agile (PO, équipe de développement, SM)
Peut être consulté par n’importe qui en dehors de l’équipe agile (management, acteurs côté client, …)
4

5. Comment et par qui construire
Par l’équipe agile en s’inspirant de la réalité, de l’historique, des problèmes rencontrés et des tâches
réalisables (specs “ready”, wireframing “ready”, dependencies-free, ...).
Initialiser à partir de sessions de “brainstorming” tenus entre l’équipe agile (SM, dev team, PO).
S’appuyer fortement sur le pattern INVEST.
Pensez au jeu Pacman (tant que les PBI ne sont pas assez “fins”, on ne peut pas les consommer !).
À consommer sans modération par l’équipe agile lors des sessions d’affinage du Backlog.
5

6. À éviter/bannir
Confondre DoR et pré-requis de tests.
Trop en faire et casser ainsi ce principe agile : “La collaboration avec les clients plus que la négociation
contractuelle”. Car un DoR pourrait rapidement devenir une sorte de “contrat” entre le PO et l’équipe de
développement (phénomène “phase-gate”).
Injecter dans le DoR des activités sans valeur ajoutée (ex : Wireframes disponibles sur Balsamiq plutôt
que moqups).
6

7. Caractéristiques
Clair et concis
Visible à toute l’équipe agile (idéalement installé au plateau sur un mur ou whiteboard)
Constitué d’activités à “valeur ajoutée”
N’est pas statique (peut évoluer dans le temps selon le contexte du projet)
7

8. Conseil d’or
Be READY to be DONE
8

9. Exemple d’un DoR de Story
La story respecte le pattern As a < type of user >, I want < some goal > so that
< some reason >
Story “Affinée”/”groomed”
RGs et Scénarios d’implémentation spécifié et validé
Story découpée en tâches réalisables-testables
Story estimée à xx pts max
Critères d’acceptance définis et validés
Wireframe disponible et validé (si UI nécessaire)
NB : le PO et le SM assument que les membres de l’équipe de développement ne dépasseront pas plus de
10% de leur capacité durant un sprint lors des sessions d’affinage
9