Une journée dans les baskets d’un Product Owner
Immergez-vous dans le quotidien d’un Product Owner afin de saisir concrètement ses problématiques, qualités, et responsabilités !
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.
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.
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 :
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
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 :
Votre Definition Of Done doit garantir à vos User Stories une viabilité sur le plan fonctionnel mais aussi en termes de qualité de code produit.
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 :
É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
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 :
Un exemple de Definition Of Done pour une User Story peut-être au minimum que :
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision