L’importance de la Définition de Prêt en agilité

La “Définition de Terminé” (également connu sous le nom de “Definition of Done” ou l’acronyme DoD) offre divers intérêts. Dans l’article présent, je vais exposer un concept fondamental qui optimise le travail d’une équipe agile sur différents aspects. Il s’agit de la « Définition de Prêt » (également connue sous le nom de “Definition of Ready” ou l’acronyme DoR), une notion négligée à tort, par de nombreuses équipes et organisations.

Comment savoir si un élément du Product Backlog peut être embarqué dans le contenu d’un Sprint Backlog ? En quoi est-il important de se poser cette question ? Ne serait-il pas plus simple de se plier simplement à la volonté du Product Owner ? Ou encore à celle des utilisateurs finaux ? 

Dans cet article, je tente de répondre à ces questions en évoquant les principes théoriques de l’agilité et leur application pratique.

Qu'est-ce que la Définition de Prêt ?

La Definition of Ready (DoR) est l’ensemble des critères définis consensuellement par l’équipe Scrum qui permettent de déterminer si une User Story (US) (ou plus généralement un élément du Product Backlog), peut être considérée comme réellement prête à faire partie du contenu d’un Sprint. On voit donc, à travers cette définition simple, l’impact crucial qu’elle peut avoir sur le déroulement d’un Sprint mais aussi sur l’incrément dans sa globalité. 

Comme pour la DoD, cette définition illustre les 3 piliers de Scrum. D’abord la transparence dans le sens où tous les membres de l’équipe Scrum se mettent d’accord si une US peut être démarrée en développement lors du prochain Sprint. Cette discussion doit avoir lieu principalement en Sprint Planning. Ensuite, l’inspection, car elle permet à toute l’équipe d’examiner la demande formulée par les utilisateurs à travers le Product Owner, et vérifier si son développement peut être démarré. Cette évaluation doit être factuelle, et doit se baser sur plusieurs critères que je définis dans la suite de l’article. Et enfin, l’adaptation, car si une US ne satisfait pas les critères définis dans la DoR, alors elle ne peut pas faire partie du Sprint, et le contenu de ce dernier doit donc être adapté en fonction de cette donnée.

Les bénéfices de la Definition of Ready ou DoR

La définition précédente nous permet de tirer plusieurs bénéfices de la DoR dans le fonctionnement d’une équipe agile en général, et Scrum en particulier. Comme pour la DoD, je les ai scindés en deux catégories:

Les bénéfices pratiques de la DoR

Ils sont nombreux, mais nous pouvons les synthétiser comme suit:

1. Fluidifier le flux de travail des Développeurs : Si une US non prête est démarrée dans un Sprint, et que le Développeur en charge de sa production se rend compte en plein Sprint qu’elle ne peut être faite (car il manque une spécification, ou encore parce que le besoin n’est pas clair, ou simplement parce que techniquement elle pourrait mettre en péril tout le produit, …), alors il aura perdu du temps. La DoR, permet d’éviter les allers-retours dans le flux du travail (entre les étapes « A fairedémarrer » et « En cours » d’un point de vue kanban), et favorise donc un flux continu de production, et par conséquent, de livraison. 
2. Garantir l’efficacité de chaque développement : cela passe par l’élimination de tout besoin de clarifier le besoin et le périmètre de la User Story en question. 
3. Protéger l’équipe Scrum: et c’est parmi les responsabilités du Scrum Master, de sensibiliser le Product Owner de l’importance qu’une US soit prête, pour le protéger auprès des utilisateurs, mais aussi d’encourager les Développeurs à poser les bonnes questions, et à être sûrs que l’expression du besoin ne comporte aucune ambiguïté.

Les bénéfices méthodologiques de la DoR

Ils sont très importants pour la fluidité du fonctionnement d’une équipe, et donc, son atteinte d’un haut niveau de performance sur le long terme. Voici un récapitulatif de ces bénéfices :

1. Faire progresser la maturité fonctionnelle et technique de toute l’équipe : En arrivant ensemble à décider si une US est prête ou non, les bonnes questions se posent, et l’intelligence collective de toute l’équipe se développe sur les aspects techniques et fonctionnels. Sur le long terme, cela permet à l’équipe de développer une connaissance approfondie du produit et du marché. 
2. Améliorer les relations : Le débat sain et constructif que nécessite la discussion sur la « readiness » d’une US, permet d’ancrer sur le long terme la transparence des échanges et des rapports humains. 
3. Protéger l’image de l’équipe et du produit : Une équipe Scrum qui sait refuser la prise en compte d’une US dans un Sprint, et qui le justifie factuellement témoigne d’une maîtrise et d’une confiance auprès des utilisateurs finaux. 

Critères indispensables dans une Definition of Ready

Je voudrais conclure cet article, de la même façon avec laquelle j’ai conclu la publication sur la DoD, en fournissant quelques éléments indispensables qui aident à formuler une DoR:

L’US en question doit être INVEST:

• Indépendante: Dans la mesure du possible, l’US ne doit avoir aucune (ou peu) de dépendance externe ou interne. Cela consiste à s’assurer que l’US ne soit pas interchangeable avec une autre, et qu’elle peut donc être réalisée à n’importe quel moment en fonction de la priorité qui lui est associée.
• Négociable: Doit favoriser la discussion et le débat pour s’assurer de sa compréhension. Une US n’est pas une liste prédéfinie d’exigences, mais une description synthétique d’un besoin utilisateur. Les détails techniques font l’objet d’une discussion entre les développeurs et le Product Owner (représentant de l’utilisateur final). 
• Valorisée: Doit avoir une valeur ajoutée pour le produit et pour les utilisateurs finaux. En effet, une US doit exprimer la valeur ajoutée qu’elle apporte à l’utilisateur final, et ne doit donc pas se contenter de lister les opérations techniques à implémenter pour la réaliser.
• Estimable: L’équipe de développement doit pouvoir estimer sa complexité. Une US ne doit pas être très générale car elle risque d’être très vague.
• Small: Suffisamment petite pour être réalisable dans un seul Sprint.Ici, il s’agit d’être simple et efficace. Le détail viendra par la suite. 
• Testable: Une US doit avoir un niveau de clarté assez élevé en exprimant d’une manière précise ses conséquences observables sur le produit et le comportement utilisateur attendu. 

L’US doit contenir des critères d’acceptation : Ils permettent d’expliquer les résultats attendus de l’utilisation de la fonctionnalité attendue.

L’US doit être démontrable : Les développeurs doivent savoir se projeter sur la façon dont ils comptent démontrer l’US lors de la Revue de Sprint.