Comment rédiger une User Story

La User Story (récit utilisateur en français) représente une pratique Agile, utilisée avant tout dans Scrum, pour «capturer» les besoins des utilisateurs en exprimant de manière générale et non détaillée, les caractéristiques, les fonctions et les exigences du produit à créer.

Les user stories font partie du Product Backlog, qui dans Scrum représente une « liste » de toutes les choses qui doivent être faites dans le projet.

Elles sont simples, mais vraiment efficaces car elles permettent de se concentrer sur les besoins et les exigences de l’utilisateur (et/ou client) et sur la valeur à atteindre. Les user stories sont souvent écrites sur papier/carton ou post-it et sont fixées au mur ou sur des tableaux blancs pour faciliter la planification et la discussion.

Grâce aux user stories, les équipent consacrent leur temps à la discussion des fonctionnalités au lieu de leur rédaction, respectant ainsi une des 4 valeurs du Manifeste Agile

« des logiciels opérationnels plutôt que de la documentation exhaustive ».

 

À quoi servent les User Stories?

Les user stories sont un excellent moyen de définir clairement le produit/service.
Un ensemble de user stories bien rédigé et hiérarchisé peut certainement aider l’équipe à exprimer et partager les fonctionnalités du produit sans entrer dans les détails techniques.

Une user story vous permet de comprendre l’importance et l’impact d’une fonctionnalité sur l’entreprise et aide à faire comprendre au client l’utilité de la fonctionnalité et sa priorité.

Si elles sont bien rédigées, les user stories fournissent une base solide pour la communication et la collaboration, amenant l’utilisateur au centre de l’attention. L’utilisation des user stories facilite les discussions sur le produit, à la fois au sein de l’équipe de développement et avec les parties prenantes externes.

 

Composition d’une user story

Chaque user story décrit ce qu’il faut faire, pour qui et pourquoi d’une manière simple et compréhensible pour le client et le développeur.

Le point de vue est celui de ceux qui demandent la nouvelle fonctionnalité, la quantité d’informations est essentielle pour permettre à l’équipe de développement de faire une estimation approximative du travail nécessaire à la réalisation.

Il existe différentes manières d’écrire une user story, mais elle contient généralement un nom, une brève description et la spécification des critères d’acceptation et des conditions pour lesquelles la user story peut être considérée comme terminée :

En tant que <type d’utilisateur>, je souhaite <le but> afin de <la raison>

Voici deux exemples:

• En tant que client, je souhaite annuler ma réservation d’hôtel afin d’obtenir un remboursement.
• En tant que client, je souhaite pouvoir me connecter afin d’accéder en toute sécurité à mon compte.

La user story rend le dialogue avec le client et/ou l’utilisateur nécessaire, car c’est grâce au dialogue que nous pouvons comprendre tous les différents aspects de la user story. Grâce à la user story, nous pouvons avoir une bonne compréhension du “quoi” et du « pourquoi” nous devons développer cette fonctionnalité spécifique.

 

Principales caractéristiques des user stories

Les user stories doivent toujours avoir 6 caractéristiques, représentées par l’acronyme INVEST,
utilisé par Bill Wake *:

• Independent : elles doivent être indépendantes les unes des autres
• Negotiable : elles doivent être «négociables» et ouvertes aux contributions de tous
• Valuable : elles doivent apporter une valeur ajoutée au client
• Estimable : elles doivent être estimables, pas exactement, mais suffisamment pour permettre une planification approximative de la mise en œuvre
• Small : elles doivent être petites, afin de pouvoir réaliser la fonctionnalité en un maximum de quelques semaines de travail. Elles doivent être petites parce que les estimations sont ainsi plus précises. Si la user story est trop complexe, il est préférable de la décomposer en plusieurs histoires.
• Testable : elles doivent pouvoir être testées et contenir des informations sur la manière de réaliser les tests.

Voici un exemple de la façon de décomposer une user story en user stories plus simples.

 

Qui écrit les user stories ?

Les user stories peuvent être rédigées par toute personne possédant les compétences nécessaires pour les rédiger. Le plus souvent, elles sont rédigées par le Product Owner.

 

Critères d’acceptation d’une user story

Avec les user stories, il est important d’élaborer des critères d’acceptation, c’est-à-dire des critères qui doivent être utilisés pour évaluer si une user story a été correctement et pleinement mise en œuvre. Ce sont donc les conditions que le produit/logiciel doit respecter pour être accepté par l’utilisateur et/ou le client. Les critères d’acceptation sont essentiels pour comprendre quand l’objectif de la user story est atteint.

 

Format d’une user story

La user story est souvent écrite sur une carte papier au format A6 ou un post-it.

Le petit format oblige à ne pas utiliser trop d’informations.
Le post-it est utile car il est simple d’utilisation et permet de regrouper les post-it sur le mur, un tableau ou sur la table afin d’évaluer la cohérence, l’exhaustivité et les connexions entre les différentes user stories.

Même si vous avez des user stories électroniques, il peut être utile d’utiliser des post-il.

Un autre facteur important est la visibilité : les user stories doivent être visibles par toute l’équipe. Après tout, elles représentent l’unité de travail que l’équipe entreprend de réaliser dans un sprint.

 

A lire également : 3 conseils pour planifier les sprints de votre projet agile

*INVEST in Good Stories, and SMART Tasks

Copyright ©  2019 Agile Business Consortium all rights reserved