Portrait d'une sublime User Story

 

Dans le monde agile, une User Story (ou US) est bien plus qu'une simple phrase sur un post-it ; c'est une entité vivante, respirant l'essence même de la fonctionnalité qu'elle décrit. En tant que Product Owner, nous pouvons l’imaginer comme une personne, une personne qui est le reflet de nos besoins, de nos attentes et de nos désirs.

 

Chaque partie de son corps représente un élément essentiel qui la compose, qui lui donne vie et sens. Laissez-moi vous emmener dans un voyage à travers l'anatomie d'une sublime User Story, où chaque composant est méticuleusement associé à une partie du corps, créant une harmonie parfaite entre forme et fonction.

 

 

Le titre : les yeux

 

Les yeux sont souvent considérés comme la fenêtre de l’âme, révélant les intentions et les émotions les plus profondes. De même, le titre d’une US est la première chose que l’on voit. Il attire l’attention et donne une vision claire de l’objectif à atteindre. Dans les tableaux agiles, le titre permet à l’US d’être visible sans surcharger d’informations. Il se doit donc d’être clair, concis et précis à la fois.

 

 

La description : le cerveau

 

Le cerveau décide des actions et commande le corps. Il est l’élément central du système nerveux. La description partage le même rôle dans une User Story. Elle détermine les actions à entreprendre, dirige le développement, articulant clairement le rôle, le besoin et le but.

 

La plupart du temps, elle prendra la forme « En tant que …, je veux …, afin de… ». Cette formulation permet de plus facilement faire ressortir les éléments essentiels qui seront portés par l’User Story, à savoir le rôle, le besoin et la valeur métier.

 

 

Le contexte : la peau

 

Le contexte d'une User Story est comme la peau d'une personne. De la même manière que la peau est l'enveloppe qui entoure notre corps, le contexte est l'encadrement métier de l'US. Il fournit le cadre métier nécessaire pour comprendre et intégrer la fonctionnalité dans l’écosystème du projet.

 

Il est important de ne pas négliger cette partie afin d’avoir la compréhension de ce qui entoure l’US. Ainsi les liens seront plus facilement faits entre les différents US. Cela améliore la précision et la compréhension de celle-ci.

 

 

Les critères d’acceptation : le cœur

 

Le cœur est vital, pompant le sang pour connecter tous les organes. Les critères d’acceptation sont tout aussi essentiels, ils permettent de faire le lien entre tous les éléments de l'US en définissant les règles métiers qui vont mettre l’ensemble en cohérence.

 

Pour ces raisons, la rédaction des critères d’acceptations doit répondre à plusieurs exigences :

• Ils doivent être écrits de manière claire et sans ambiguïté.
• Il doit être possible de concevoir un test ou plusieurs tests qui confirment si le critère a été atteint ou non.
• Ils doivent être directement liés aux objectifs de l'User Story et contribuer à sa valeur ajoutée. Ils ne doivent pas inclure de fonctionnalités superflues ou hors-sujet.
• L'ensemble des critères doit couvrir tous les aspects de l'User Story que, une fois tous validés, la fonctionnalité soit complète;

 

Il est recommandé d’écrire chaque critère avec la formulation « Etant donné…, quand …, alors… » :

•  « Etant donnée » met l’accent sur l’utilisateur et son besoin. Cela aide à garder l’utilisateur au centre de la conception et du développement.
• “Quand” permet de définir le contexte ou la situation dans laquelle l’utilisateur se trouve. Cela aide à comprendre quand et comment la fonctionnalité sera utilisée.
• “Alors” définit le résultat attendu ou le bénéfice pour l’utilisateur. Cela donne une vision claire de ce que la fonctionnalité doit accomplir.

 

 

La maquette : le visage

 

Le visage est notre carte de visite, la première impression que nous laissons. Une maquette joue un rôle similaire pour l’US, illustrant visuellement la fonctionnalité et aidant à se souvenir des détails importants.

 

 

Les informations complémentaires : l’appendice

 

L’appendice est un élément qui peut être absent dans la plupart des cas. Mais il peut également être précieux pour la santé intestinale. C’est également le cas de la rubrique des informations complémentaires, qui peux s’avérer précieuses pour clarifier les aspects techniques ou métiers de l’US. On peut y mentionner des informations documentaires, des précisions importantes sur les jeux de données utiles à l’User Story, par exemple.

 

 

Les questions et arbitrages métier : l'estomac

 

Les questions et arbitrages métier d'une User Story sont comme l'estomac d'une personne. Tout comme lui, il permet d'en ressortir les éléments d'une première digestion des informations de l'US. De cette digestion va en ressortir possiblement des questions et/ou des demandes d'arbitrage. Cette section permet d'y garder une trace. Ainsi, ces informations seront alors conservées, ce qui évitera de les produire à nouveau.

 

 

Les scénarios d’acceptation : les jambes

 

Les jambes sont l'élément qui permet la mise en mouvement. C’est aussi ce qu’on retrouve en bas du corps. De la même manière, les scénarios d'acceptation, en bas de l’User Story, vérifient qu’elle est fonctionnelle et prête à être mise en œuvre. Qu’elle « marche » en somme.

 

Les scénarios d'acceptations seront plus utiles dans les derniers instants de vie de l'US, à la fin des développements. Ils doivent couvrir l’ensemble des cas généré par les critères d’acceptation. Ils peuvent également contenir des scénarios de non-régression afin de vérifier que les développements de l’User Story n’auront pas dégradé un comportement existant voisin.

 

 

Bonus – La DOR (Definition Of Ready) et la DOD (Definition Of Done) : le scanner

 

Tout comme un scanner médical examine notre corps pour s’assurer que tout est en place et fonctionne correctement, la DOR et la DOD examinent l’US pour s’assurer que tout est prêt pour le développement et la livraison :

• La DOR, comme un scanner pré-opératoire, vérifie que toutes les conditions sont remplies avant que l’US ne soit prise en charge par l’équipe de développement. Elle s’assure que l’US est suffisamment bien définie et comprise par tous, prête à être “opérée” par l’équipe de développement.
• La DOD correspondrait plutôt au scanner post-opératoire, permettant de vérifier que tout a été correctement mis en place.

 

 

Pour conclure :

 

En parcourant l'anatomie d'une User Story, nous avons découvert que chaque élément joue un rôle crucial pour garantir la clarté, la cohérence et l'efficacité des développements agiles. De ses yeux, qui captent l'essentiel avec le titre, jusqu'à ses jambes, qui mettent en mouvement les scénarios d'acceptation, une User Story bien construite est un atout majeur pour tout projet.

 

Tout comme le corps humain évolue et s'adapte, les User Stories doivent également être flexibles et réactives aux changements de l'environnement du projet. Elles doivent respirer au rythme des besoins des utilisateurs et battre au cœur des objectifs métier.

 

Mais cette exploration ne s'arrête pas là. Chaque User Story est une opportunité de réflexion et d'amélioration continue. En tant que Product Owner, il est de notre responsabilité de questionner constamment nos pratiques : comment pouvons-nous affiner encore plus nos descriptions ? Quels outils pouvons-nous mettre en place pour mieux intégrer le feedback de l'équipe et des utilisateurs ? Comment garantir que chaque User Story reste alignée avec les objectifs stratégiques de l'entreprise ?

 

Et vous, chers lecteurs, comment voyez-vous l'évolution des User Stories dans vos projets ?