Un sprint démarre. L’équipe lit les tickets. “Ajouter un champ date dans le formulaire X.” “Modifier la couleur du bouton Y.” “Améliorer l’expérience utilisateur du module Z.”
Tout le monde se regarde. Qui est l’utilisateur derrière ça ? Quel problème on résout ? Comment on saura que c’est terminé ? Silence. On passe au sprint suivant… et les irritants métiers restent entiers.
C’est ça, le piège classique : des “User Stories” qui n’en sont pas. Des tâches techniques, des demandes isolées, ou des formulations vagues qui ne guident rien. Résultat : un backlog qui gonfle, des sprints qui livrent des fonctionnalités, mais peu de valeur réelle.
👉 Une vraie User Story, c’est autre chose : un outil de cadrage simple et actionnable, qui met l’utilisateur au centre et qui permet à l’équipe de décider vite, de développer juste et de tester sans interprétation.
Dans cet article, on vous propose un guide pas-à-pas pour écrire des User Stories qui tiennent debout : compréhensibles, testables, et directement connectées aux objectifs produit.
Partir du besoin utilisateur, pas de la solution technique
Le réflexe courant : écrire directement ce qu’on veut coder. “Ajouter un champ commentaire”, “Créer une API d’export Excel”, “Changer l’ordre des colonnes”.
… sauf que ne sont pas des User Stories. Ce sont des tâches. Elles ne disent rien du pourquoi ni de pour qui.
Une bonne User Story commence toujours par un irritant utilisateur réel. Pour le trouver, on retourne au terrain :
- Observer un parcours clé : inscription, saisie d’un formulaire, recherche d’une info.
- Identifier où ça bloque : trop de clics, infos manquantes, lenteur.
- Reformuler en problème utilisateur, pas en idée de solution.
Exemple :
❌ “Ajouter un champ date dans le formulaire.”
✅ “En tant que gestionnaire, je veux renseigner une date d’échéance pour savoir quelles demandes traiter en priorité.”
Dans le premier cas, on a une consigne technique. Dans le second, on a un besoin clair, contextualisé, qui aide à comprendre la valeur.
⚡ En pratique
Avant d’écrire une User Story, demandez-vous toujours :
- Qui est l’utilisateur concerné ?
- Quelle friction rencontre-t-il vraiment ?
- Quelle valeur attend-il en sortie ?
Si vous ne pouvez pas répondre à ces trois questions, vous n’avez pas une User Story. Vous avez une tâche.
Structurer avec le format “As a / I want / So that”
Le format classique des User Stories, c’est un cadre qui oblige à se poser les bonnes questions et à éviter les specs déguisées.
La structure :
- As a [persona / rôle] → qui est l’utilisateur ?
- I want [objectif concret] → que veut-il faire ?
- So that [valeur attendue] → pourquoi c’est important ?
👉 Exemple : “En tant que gestionnaire RH, je veux filtrer les candidatures par compétence afin de gagner du temps dans la présélection.”
Ici, on a :
- un rôle clair (gestionnaire RH) ;
- une action explicite (filtrer les candidatures) ;
- une valeur métier mesurable (gagner du temps dans la présélection).
❌ Les erreurs fréquentes à éviter :
Zapper le “So that” → on se retrouve avec une action sans impact.
Utiliser “En tant qu’utilisateur” → trop générique, ça ne dit rien.
Mettre deux besoins en un seul → impossible à prioriser ou à tester.
⚡ Pro tip
Testez vos User Stories à l’oral. Si une personne extérieure à l’équipe ne comprend pas en 10 secondes qui fait quoi et pourquoi, reformulez.
Définir des critères d’acceptation clairs
La pire phrase qu’on entend en sprint review : “Ah, mais ce n’est pas ce qu’on avait demandé…” Ce flou ne vient pas (seulement) du dev ou du PO. Il vient d’une User Story sans garde-fous.
Les critères d’acceptation sont là pour ça : poser la frontière entre “c’est livré” et “c’est encore en chantier”.
Prenons un exemple : “En tant que gestionnaire RH, je veux filtrer les candidatures par compétence afin de gagner du temps dans la présélection.”
👉 Si on s’arrête là : trop vague. Certains imaginent un simple champ texte. D’autres, une liste déroulante intelligente. Résultat ? Débats, retards, frustrations.
Ajoutons les critères :
- Le filtre propose les compétences déjà définies dans le back-office.
- Je peux en combiner plusieurs à la fois.
- Le résultat s’affiche en moins de 2 secondes.
- S’il n’y a rien, un message clair me le dit.
Avec ces 4 lignes, plus de débat. Tout le monde sait ce qui est “done”.
La règle : pas besoin de 10 critères. Trois à cinq bien choisis suffisent. Trop, et votre story est trop large. Zéro, et vous laissez la porte ouverte aux interprétations.
💡À tester : le format Given / When / Then
Petit plus si vos équipes aiment la rigueur : le format Given / When / Then. Pas pour faire joli, mais pour décrire un vrai scénario d’usage :
- Given une liste de candidatures,
- When je sélectionne “Java” dans le filtre,
- Then seules celles avec “Java” apparaissent.
C’est ce qui transforme une user story floue en base solide pour coder, tester… et livrer sans surprise.
Découper en user stories actionnables
Une story trop grosse, c’est une bombe à retardement : impossible à estimer, interminable à développer, et jamais vraiment “finie”.
La solution n’est pas de la réduire au hasard, mais de la découper par valeur.
Prenons l’exemple d’une recherche avancée.
La story d’origine : “En tant qu’utilisateur, je veux une recherche multicritères pour trouver rapidement l’information.”
Si on livre ça d’un bloc, on part pour trois sprints. Et pendant ce temps, aucun feedback.
Découpons intelligemment :
- Étape 1 — Filtre simple : un seul critère, mais déjà utilisable.
- Étape 2 — Filtres combinés : possibilité d’en croiser deux.
- Étape 3 — Sauvegarde des recherches : confort, mais pas vital au départ.
Chaque étape est testable, apporte de la valeur, et permet d’apprendre.
👉 Le bon découpage, ce n’est pas “front/back” ou “UX/API”. Ce sont des tranches verticales : chaque sous-story doit être utilisable seule, même si limitée.
💡 Astuce :
Si votre story ne rentre pas dans un sprint, elle est trop grosse.
Et si vous hésitez sur la découpe, demandez-vous : “Quel est le plus petit pas qui apporte déjà de la valeur à l’utilisateur ?”
Prioriser et relier les user stories aux objectifs produit
Un backlog rempli, ça impressionne sur le papier. Mais sans priorisation claire, c’est juste une pile de demandes où tout semble important… et rien ne l’est vraiment. On développe au fil de l’eau, selon qui parle le plus fort, et la valeur se dilue.
Une bonne User Story doit toujours être reliée à un objectif produit précis. Sinon, elle reste décorative. Prenons deux exemples :
❌ “Changer la couleur du tableau de bord.”
✅ “En tant que chargé de support, je veux rechercher un ticket par numéro afin de réduire le temps de réponse.”
Dans le premier cas, difficile de dire si ça apporte quoi que ce soit. Dans le second, le lien est direct avec l’objectif produit “réduire le temps moyen de traitement”. C’est mesurable, c’est actionnable.
La clé, ce n’est pas de dire oui ou non à une story. C’est de demander systématiquement : “À quel objectif produit contribue-t-elle ?” Si la réponse n’existe pas, elle n’a pas sa place dans le sprint.
⚡ En pratique :
Affichez vos objectifs au-dessus du board. Chaque User Story doit pouvoir se rattacher à l’un d’eux en une phrase. Si ce n’est pas le cas, c’est un signal fort qu’elle doit être revue ou mise de côté.
La checklist express avant de mettre une User Story en sprint
Avant qu’une User Story n’entre en sprint, passez-la au crible. Si elle échoue sur un point, c’est un signal fort qu’elle n’est pas prête.
✅ Rôle clair : le persona est identifié, pas “utilisateur” générique.
✅ Besoin formulé : objectif écrit en une phrase compréhensible hors équipe tech.
✅ Valeur attendue : “So that” mesurable, pas un vœu pieux.
✅ Critères d’acceptation : 3–5 max, couvrant le cas nominal et une erreur.
✅ Découpée : tenable dans le sprint (sinon, sous-stories prévues).
✅ Lien aux objectifs produit : quel KPI ou KR bouge si on la livre ?
Imprimez cette checklist et posez-la dans la salle de refinement. Moins de flou, plus de stories solides, et des reviews qui cessent d’être des séances de recadrage.
Conclusion — Des User Stories qui guident, pas qui encombrent
Une User Story bien écrite, ce n’est pas une ligne de plus dans Jira. C’est un outil de décision : elle dit qui, quoi, pourquoi et comment on saura que c’est terminé.
👉 Les règles qui font la différence :
- partir d’un irritant utilisateur, pas d’une idée technique ;
- garder le format “As a / I want / So that” pour cadrer sans jargon ;
- poser 3–5 critères d’acceptation clairs pour éviter les débats ;
- découper en tranches de valeur testables ;
- et relier chaque story à un objectif produit concret.
Sans ça, vous accumulez des tickets. Avec ça, vous construisez un backlog qui oriente, un sprint qui délivre de la valeur, et une équipe qui sait pourquoi elle code.
Vous avez l’impression que vos stories ressemblent plus à des “to-do techniques” qu’à de vrais besoins utilisateurs ? Parlons-en. En 30 minutes, on peut analyser vos pratiques actuelles, identifier les points faibles et poser les bases d’un backlog qui délivre enfin de la valeur.
