Qu’est-ce qu’une User Story ?  Pourquoi écrit-on des User Stories ?  Comment rédiger les meilleures User Stories ? Quels sont les bonnes pratiques ? Quels sont les pièges à éviter ?

Je vous dis TOUT dans cet article ! 🧐

 

Tout d’abord, un peu d’Histoire…

 

La User Story ou « US » n’est pas à proprement parler un élément du cadre méthodologique Scrum, cette pratique nous vient de l’Extreme Programming. Pourtant, cet élément est largement utilisé dans le cadre de projets agiles, menés en Scrum ou Kanban, au point d’être devenu la référence des formations agiles certifiantes.

Les approches agiles ont repris certaines choses qui fonctionnaient bien avant :

• On recueille les besoins
• On recherche des idées innovantes
• On monte des groupes de réflexion et des ateliers de travail

Pour autant,

• On ne cherche plus à tout définir à l’avance
• On commence par ce qui a le plus de valeur
• On se concentre sur le point de vue de l’utilisateur / du client
  
• On affine le besoin directement avec les développeurs et les testeurs

 

Qu’est-ce qu’une User Story ?

User Story (« US »), signifie littéralement « récit de l’utilisateur ».
L’User Story est issue d’un découpage fonctionnel d’une EPIC, soit une « grande histoire » (= une grande fonctionnalité). Ce morceau fonctionnel apporte de la valeur à l’utilisateur. Il est  testable et utilisable, même si la fonctionnalité n’est pas encore complète. L’assemblage des User Stories et des EPICs développées, testées et livrées à l’utilisateur forme un tout cohérent et de valeur, appelé « Incrément » (= morceau du produit) ou « Produit ».

Ce découpage en User Stories n’est pas seulement utile pour formaliser correctement, rapidement et efficacement les éléments fonctionnels, il permet également de mieux contrôler la qualité des incréments et de mieux piloter la production.
A ce titre, ce découpage fonctionnel permet de suivre précisément l’exécution du produit => ce qui est acquis n’est plus à faire !

Pour avoir été un acteur de la MOA (Maitrise d’ouvrage), j’ai tout de suite adhéré à cette approche pragmatique et empathique (= c’est à dire centré sur l’utilisateur de notre service ou produit).
Cette description fonctionnelle est utilisée dans les méthodes agiles pour spécifier le développement, les tests et la validation d’une fonctionnalité.
La formalisation est écrite en langage naturel pour éviter les longues descriptions d’une technologie spécifique ou de l’organisation d’une base de données, par exemple. Ainsi, tous les acteurs se comprennent et avancent en ayant la même compréhension des choses.

Concrètement les User Stories sont généralement initiée par des acteurs métiers / fonctionnels qui expriment les besoins. Le Product Owner (représentant des utilisateurs, dans le cas d’une équipe SCRUM) explicite ce besoin, l’enrichit et le décrit sous forme de morceaux fonctionnels : les EPICs et les User Stories.

En qualité de coach agile, je recommande que le Product Owner rédige les User Stories collégialement avec un des développeurs et un des testeurs (cette relation tripartite s’appelle les 3 amigos ») pour s’assurer de la bonne compréhension et de la complétude des récits de l’utilisateur.
Par expérience, ce mode de travail à 3 est plus long au moment de la spécification mais le temps investi, en amont, est largement rentabilisé lors de l’exécution, des tests et des livraisons.
Ce fonctionnement apporte une vraie cohésion par une meilleure compréhension, une meilleure qualité et une meilleure collaboration entre chaque membre de l’équipe.

«  N’oubliez pas que le produit livré à vos utilisateurs / clients est la résultante de la compréhension de vos développeurs ! »

 

Quelle est la définition d’une User Story ?

Ma définition d’une User Story est la suivante :

«  Une User Story est le juste formalisme pour qu’une équipe agile puisse développer, tester, intégrer et livrer correctement un élément fonctionnel. »

D’autres experts diraient : « Une User Story est une invitation à avoir une conversation avec son client et l’équipe sur un sujet particulier. »

Quel que soit votre définition d’une User Story, l’important est que l’équipe fonctionne correctement pour livrer au mieux et au plus vite le meilleur produit possible : utile, utilisable et désirable.

 

Comment rédiger une bonne User Story ?

Selon Ron Jeffries, l’un des 3 fondateurs de la méthode Extreme programming (XP) créé en 1996 et l’un des 17 signataires du Manifeste Agile, une bonne User Story se définit par l’addition de 3 composantes, nommé les «  3 C », soit : CARTE + CONVERSATION + CONFIRMATION.

C’est 3 éléments sont cruciaux pour s’assurer de la bonne exécution de votre demande et de la qualité de votre livraison.

#1 – La narrative

Au fil des années, différents modèles de formulation ont émergé, voici mon préféré :

En tant que <utilisateur>, je veux <verbe d’action> afin de <d’obtenir un bénéfice>.

On retrouve les 3 questions essentielles : POUR QUI ?, QUOI ? et POURQUOI ?.

En anglais, cette narrative devient :

As a <type of user>, I want <some goal> so that <some reason>.

 

#2 – Les notes

Les notes sont des éléments qui peuvent être utiles aux acteurs qui réaliseront, testerons et validerons l’élément fonctionnel décrit. Dans une User Story et si cela apporte de la valeur à l’équipe de réalisation, nous pouvons rajouter : le contexte, les règles de gestion, les maquettes graphiques, les cas nominaux et aux limites, la documentation à disposition en pièce jointe, les contraintes techniques particulières, etc.

Mon conseil de coach agile : Pensez toujours à vos lecteurs et à la simplicité de votre rédaction. Plus votre description sera longue, plus il y a de chance qu’elle soit lue en diagonale… et donc que des choses soient négligées, voire oubliées ! Soyez clair et efficace !

 

#3 – Les exemples ou critères d’acceptation

Les exemples ou les critères d’acceptation permettent d’établir si l’élément fonctionnel est « terminé », vraiment « terminé » !
C’est-à-dire que toutes les étapes de réalisation, de tests qualité et de validation ont été mené correctement. La qualité est non négociable en approche agile.

Les critères d’acceptation précisent les limites et le comportement attendus par l’applicatif. En réduisant le champ de l’incompréhension, on améliore mécaniquement la qualité livrée.

Mon conseil de coach agile : en addition de ces conseils, je vous invite aussi à fournir des jeux de tests variés afin de couvrir un maximum de combinaisons fonctionnelles, soit les cas les plus fréquents, les cas aux limites, non-passants et les plus bizarres qui pourraient créer des anomalies ou des comportements non-désirés. Les tests sont l’une des clés de votre qualité !

 

Quelles sont les caractéristiques d’une bonne User Story ?

Selon moi, une bonne User Story se définit par :

• Compréhensible par tous
  Pas de terme technique, juste du langage naturel
• Raconte une histoire liée à un ou plusieurs utilisateurs.
  Un parcours de bout en bout est préférable, même simple, et qui sera enrichi par la suite.
• Légère et simple à rédiger.
  Allez à l’essentiel, pas de baratin !
• Suffisamment claire
  pour permettre aux développeurs d’estimer sa faisabilité
• Réalisable entièrement durant un sprint
  Une limite de 3 à 4 jours de réalisation et de test est un bon repère.

Et si vous voulez être fort comme Hulk, INVEST-issez dans de bonnes User-Stories !

« INVEST » est l’acronyme mnémotechnique inventé par Bill WAKE pour retenir les caractéristiques d’une bonne User Story :

 I – Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres user stories induisent des problématiques de testabilité et de planification.

N – Négociable : elle doit amener à la discussion et peut-être modifiée jusqu’à son inclusion dans une itération.

V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la User Story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur.

E – Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer.

S – Small : elle doit être de taille assez petite pour prioriser de façon sûre et éviter les effets tunnels. Essayez donc au maximum de découper finement vos user stories.

T – Testable : la User Story doit raconter une histoire, dont les tests découlent de façon évidente.

 

La conclusion de l’Oeil de Coach 🧐

«  Le meilleur format d’une User Story est celui qui fonctionne avec votre équipe ! »

• Gardez en tête qu’une User Story est avant tout une histoire qui se raconte !
  Elle amène la discussion et aide l’équipe (fonctionnels, développeurs et testeurs)
  à confirmer sa compréhension du besoin.
• N’hésitez pas à abuser des dessins, maquettes graphiques, schémas, etc.
  ▶ Une image vaut mille mots !
• Ne soyez pas dogmatique, écrivez les user stories dont l’équipe a besoin pour développer et tester : ni plus, ni moins !
• Demandez régulièrement à l’équipe ce qui peut être amélioré !
  Les développeurs et les testeurs sont vos alliés ! 😉

 

▶ En BONUS : Téléchargez GRATUITEMENT l’ensemble de ces conseils au format Powerpoint (.PPT) !

 

Avez-vous aimé cet article ? Partagez-le !
Et, pensez à vous abonner à la newsletter gratuite de l’Oeil de Coach. 😉

Source image : inconnue

……… ✂……………………………… ✂………………………………… ✂…………………………………

Envie d’aller plus loin ?

• [LIVRE] User stories: 50 clés pour raconter les besoins utilisateurs de Gojko ADZIC
• [LIVRE] Le story mapping – Visualisez vos user stories pour développer le bon produit de Jeff PATTON
• [OEIL] Comment s’en sortir pour écrire vos User Stories ?
• [OEIL] Qui fait quoi dans une équipe Scrum ?
• [OEIL] Le Product Ownership Agile en résumé – et en poster
• [OEIL] Le top des ressources agiles de l’Oeil de Coach
• [OEIL] Les meilleurs outils numériques du professionnel efficace !

……… ✂……………………………… ✂………………………………… ✂…………………………………

 

En quoi puis-je vous aider ?

Je suis Martial SEGURA, Coach agile | Expert organisationnel chez Oeil de Coach.

« Mon intention est d’aider les personnes, les équipes et les organisations à atteindre leurs objectifs beaucoup plus vite qu’ils ne le feraient sans ma contribution. »

Je développe le potentiel et les savoir-faire des équipes et des personnes. J’accompagne la transformation agile des organisations, en m’appuyant sur la culture, les valeurs et les pratiques agiles.

Contactez-moi pour en parler :

🚀 Linkedin : https://www.linkedin.com/in/martialsegura
🌐 Blog : www.oeildecoach.com