Rédigez vos User Stories pour parler le langage du client

Avoir une équipe et une méthode, c’est bien. Mais que faire des centaines d’idées qui arrivent en vrac ? Comment décider par quoi commencer et dans quel ordre avancer ?
Dans cette partie, vous allez apprendre à structurer vos besoins grâce aux User Stories, à les estimer avec des méthodes simples, et à prioriser avec des techniques éprouvées.

Quand on rédige des spécifications trop techniques, on oublie souvent l’essentiel : pour qui on développe, ce qu’il veut faire et pourquoi.

Par exemple, écrire : « Créer une API REST pour l’authentification utilisateur avec JWT tokens et base de données MySQL » n’aide pas à comprendre la valeur réelle de la fonctionnalité. À l’inverse, une User Story exprime le besoin dans un langage simple et centré sur l’utilisateur : « En tant qu’utilisateur, je veux créer un compte afin de personnaliser mon expérience et retrouver mes contenus favoris. »

Cette différence illustre bien pourquoi les User Stories sont essentielles : elles mettent en avant la valeur pour l’utilisateur, plutôt que les détails techniques. Voyons maintenant comment les formuler correctement.

La formule magique des User Stories

Une User Story efficace suit une structure simple en trois parties.

1. "En tant que [qui]" - Identifier l'acteur

Cette partie définit QUI a ce besoin. C'est crucial car différents utilisateurs ont des besoins et des droits différents !

Exemples : utilisateur anonyme (visiteur qui découvre l'app), abonné premium (utilisateur qui paie), etc. 

2. "Je veux [quoi]" - Décrire le besoin

Cette partie décrit CE QUE l'utilisateur veut faire. Restez simple et concret !

Exemple : regarder une vidéo ou créer une playlist. 

3. "Afin de [pourquoi]" - Expliquer la valeur

Elle explique POURQUOI c'est utile.

Cette section permet de :

• montrer que le besoin est réel et pertinent,

• prioriser les fonctionnalités selon leur impact,

• réfléchir à des solutions alternatives possibles.

Exemple : afin de personnaliser mon expérience et retrouver mes contenus favoris.

Erreurs fréquentes à éviter

Bien que la formule soit simple, certaines erreurs sont fréquentes :

• Oublier le "pourquoi"

Ici, la demande n’apporte aucune valeur réelle.

• Rester trop vague

Ces erreurs nuisent à la compréhension du besoin et rendent la priorisation plus difficile. Veillez toujours à formuler vos User Stories de manière claire, précise et centrée sur la valeur pour l’utilisateur. 

Rendre vos User Stories testables

Écrire une User Story claire est un bon début, mais comment être sûr qu’elle est vraiment terminée ? C’est là qu’interviennent les critères d’acceptation : une liste de conditions précises que la Story doit remplir.

Si on reprend notre exemple : “En tant qu’abonné, je veux continuer la lecture d’un film là où je l’avais laissée afin de ne pas perdre le fil de l’histoire.”
Les critères d’acceptation seraient :

• L’application enregistre automatiquement la position exacte (en minutes/secondes) quand l’utilisateur quitte la vidéo.

• Lorsqu’un utilisateur revient sur le film, la lecture reprend à l’endroit sauvegardé.

• L’utilisateur peut choisir de reprendre ou de redémarrer depuis le début grâce à un message clair (ex. : “Reprendre à 32:45 ou recommencer ?”).

• La fonction doit fonctionner sur mobile et desktop.

• Si l’utilisateur change d’appareil (ex. : quitte sur son smartphone, reprend sur son ordinateur), la reprise se fait au bon endroit.

• En cas de perte de connexion internet, la reprise est toujours enregistrée et appliquée après reconnexion.

Ces critères servent de référence lors des tests : si tous sont respectés, la Story est validée. Ces critères sont essentiels pour clarifier les attentes entre le Product Owner et l’équipe de développement mais aussi réduire les malentendus (“je pensais que…”).

Enfin, les critères d’acceptation servent de base aux tests fonctionnels : chaque critère devient un cas de test à valider.

• Exemple de test n°1 : Quitter une vidéo à 25 min → rouvrir → lecture reprend à 25 min.

• Exemple de test n°2 : Quitter une vidéo sur smartphone → rouvrir sur ordinateur → lecture reprend au même endroit.

À vous de jouer

Contexte 

Vous développez une application de streaming musical comme Spotify.
Voici un retour de l’équipe marketing : “Il faut qu’on puisse écouter de la musique quand on n’a pas Internet."

Consignes 

Transformez cette demande client en une User Story qui est bien formulée et listez ses critères d’acceptation.

Livrable

En résumé

• Les User Stories remplacent les spécifications techniques par un langage centré utilisateur avec la formule : "En tant que [qui] je veux [quoi] afin de [pourquoi]".

• Formuler correctement une User Story évite de développer des fonctionnalités inutiles en se concentrant sur la valeur métier.

• Les critères d'acceptation rendent les User Stories testables avec des conditions précises à remplir.

• Chaque critère d'acceptation devient un cas de test pour valider la User Story.

Une fois les besoins exprimés clairement, il faut pouvoir estimer leur complexité pour planifier efficacement.