Background color
A black and white photo of a bench.
Produit
4
minutes
2021-03-21

Comment créer une bonne User Story en utilisant les DOR & DOD

Definition Of Ready et Definition Of Done, les critères qui vont aider à valider vos User Stories pendant leur cycle de vie

Vladimir
Product Manager
Dans cet article

Il y a une phrase que vous avez forcément déjà entendue au cours d’un sprint : “si tu as besoin de précision sur une des User Stories, viens me voir et je t’expliquerai”. Phrase pleine de bonnes intentions mais caractéristique d’un problème bien défini : si une User Story est bien conçue, elle ne génère pas de question ni d’explication complémentaire.

DOR & DOD : qu’est ce que c’est ?

Ne pas préciser ses User Stories en amont, c’est prendre le risque de voir des différences non voulues entre la fonctionnalité spécifiée et celle développée. Ce principe se retrouve parfaitement dans le concept informatique “garbage in, garbage out”. Ce concept met en lumière que si les données en entrée du programme sont de mauvaise qualité, le résultat en sortie sera de mauvaise qualité. C’est ainsi que deux termes sont apparus pour définir le minimum vital pour qu’une User Story soit viable avant puis après son développement : Definition Of Ready et Definition Of Done.

📚 Lire notre article concernant les sprints agiles.

📚 Lire notre article sur les User Stories.

Definition Of Ready (DOR)

On peut résumer la Definition of Ready de Scrum en une phrase : il s’agit de l’état d’une User Story à l’instant où l'ensemble de l’équipe produit estime qu’elle est prête à être développée. Il s’agit donc d’une User Story prête à être attribuée, suffisamment détaillée pour qu’un développeur puisse la réaliser, et avec les bons critères d’acceptance pour qu’elle passe l’homologation de son Tech Lead.

Pour rédiger votre Definition Of Ready, commencez simplement par les critères d’acceptance de base :

  • un titre explicite
  • une description ou proposition de valeur (“En tant que … je souhaite… alors…”)
  • une estimation de la charge
  • des critères d’acceptance

Une fois les bases posées, le plus pertinent pour créer une Definition Of Ready est d’interroger votre équipe : quelles sont les difficultés souvent rencontrées au moment de lire les User Stories ? Pourquoi avons-nous perdu du temps ? Ce sont les points qu’il faudra aborder en priorité ?

📚 Lire notre article sur Scrum.

DOR : valider votre User Story

DOR : valider votre User Story

Definition Of Done (DOD)

Definition Of Done Scrum : il s’agit de l’état d’avancement d’une User Story, considérée comme “prête à être déployée”.

Cela signifie par exemple que l’entièreté de la User Story est réalisée, le code est validé par le Tech Lead et elle a passé avec succès l’homologation du Product Owner ainsi que les tests unitaires. Mais comment procède-t-on ?

Il est inutile de paralyser notre processus de validation avec une liste interminable de points de vérifications, mais nous y reviendrons plus tard. Néanmoins gardez en tête que votre Definition Of Done est insuffisante si votre User Story :

  • ne passe pas les tests ou est intestable ;
  • est impossible à merger avec la branche master ;
  • est impossible à déployer.

Votre Definition Of Done doit garantir à vos User Stories une viabilité sur le plan fonctionnel mais aussi en termes de qualité de code produit.

Sois agile, pense facile

Il ne faut pas que la Definition of Ready ou la Definition of Done deviennent un frein ou une étape trop chronophage lors de vos cérémonies. Il faut bien garder en tête qu’elles ne sont pas des cérémonies Scrum, voyez plus cela comme des indicateurs de validation.

Soyez agile et pensez facile. Établissez quatre “bullet points” par définition en début de projet. Il y a trois avantages à cela :

  • la mise en place de ce squelette de Definition Of Ready et Definition Of Done sera rapide à mettre en place ;
  • vous n’érigerez pas une montagne de vérifications excessives pour votre produit ;
  • vous gagnerez la confiance et l’adhésion de l’équipe plus facilement en restant concis.

Évidemment, il est possible d’ajouter des critères d’acceptance au fil de l’eau. C’est même conseillé, vous aurez ainsi une Definition Of Ready et une Definition Of Done adaptées à votre produit.

Cycle de vie d’une User Story

Cycle de vie d’une User Story

La recette d’une DOR et d’une DOD

Il serait utile d’obtenir la recette magique d’une Definition Of Ready ou d’une Definition Of Done. Malheureusement, une telle recette n’existe pas. Chaque produit, chaque projet implique des spécificités propres.

Cependant, il est possible d’avoir un squelette de départ que vous serez amené à étayer et compléter.

Un exemple de Definition Of Ready pour une User Story peut-être au minimum que :

  • elle a été débattue par l’équipe de Dev et le Product Owner ;
  • son développement implique une vraie valeur ajoutée;
  • la charge a été estimée ;
  • cette charge rentre dans un unique sprint de développement ;
  • des critères d’acceptance ont été rédigés.

Un exemple de Definition Of Done pour une User Story peut-être au minimum que :

  • les tests unitaires sont validés ;
  • la revue de code du Tech Lead est validée ;
  • la branche de dev est “mergée” dans la branche master ;
  • les critères d’acceptance de la fonctionnalité sont validés ;
  • la feature est déployée en QA (si vous avez des équipes QA).
Parlons produit

Échangeons sur votre produit

Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision

background color