Outil gratuit

Modèle et générateur de user story gratuits

Transformez un rôle, un besoin et un bénéfice en une user story agile propre avec ses critères d'acceptation — puis copiez ou téléchargez le Markdown. Sans inscription, rien ne quitte votre navigateur.

Tout s'exécute dans votre navigateur — rien n'est envoyé ni stocké.

Votre user story

Une story ne vaut que la demande qui la porte. Dans AIOProductOS, une story transporte le compte et le revenu qui l'ont demandée — votre backlog se classe donc selon qui paie, pas selon qui a crié le plus fort.
Classer les stories par revenu Voir le PM sur la colonne vertébrale

Ce qui fait une bonne story

Petite, vérifiable et rattachée à un pourquoi.

Gardez le bénéfice réel. « Afin de pouvoir les acheter plus tard » vaut mieux que « afin que la fonctionnalité existe » — si vous ne pouvez pas nommer le bénéfice, questionnez la story.

Rendez le « terminé » vérifiable. Des critères Étant donné/Quand/Alors transforment une story vague en quelque chose que la QA et l'équipe peuvent vérifier sans réunion.

Découpez ce qui ne tient pas. Si elle demande une douzaine de critères ou déborde du sprint, c'est un epic — découpez-le en stories qui livrent chacune quelque chose.

À copier

Le modèle de user story

En tant que [rôle],
je veux [fonctionnalité]
afin de [bénéfice].

Critères d'acceptation
- Étant donné [contexte], quand [action], alors [résultat].
- Étant donné [cas limite], quand [action], alors [résultat].

Voilà tout le modèle de user story : un rôle, un besoin, un pourquoi et des critères d'acceptation Étant donné/Quand/Alors vérifiables. Collez-le tel quel dans votre outil de suivi — ou utilisez le générateur ci-dessus pour le remplir et télécharger le Markdown.

FAQ

Questions sur les user stories

Qu'est-ce qu'une user story ?
Une user story est un énoncé court, en langage courant, d'une fonctionnalité du point de vue de l'utilisateur, sous la forme : « En tant que [rôle], je veux [fonctionnalité], afin de [bénéfice]. » Elle capture qui veut quelque chose, quoi et pourquoi — et laisse l'implémentation à l'équipe.

Quel est le format d'une user story ?
Le modèle standard est « En tant que [type d'utilisateur], je veux [une action ou une capacité], afin de [un bénéfice ou une raison]. » Les bonnes stories sont accompagnées de critères d'acceptation — des conditions vérifiables, souvent écrites en Étant donné/Quand/Alors — qui définissent quand la story est terminée.

Que sont les critères d'acceptation ?
Les critères d'acceptation sont les conditions précises et vérifiables qu'une user story doit satisfaire pour être considérée comme terminée. Un format courant est Étant donné/Quand/Alors : étant donné un contexte, quand l'utilisateur fait quelque chose, alors un résultat précis se produit. Ils rendent la story vérifiable par la QA et l'équipe.

Ce générateur de user story est-il gratuit ?
Oui — gratuit, sans inscription ni mur d'e-mail. Tout s'exécute dans votre navigateur ; rien de ce que vous saisissez n'est envoyé. Remplissez les champs, puis copiez le Markdown ou téléchargez le .md dans Jira, Linear, Notion ou votre board.

Quel niveau de détail pour une user story ?
Assez petite pour être terminée dans une itération, avec assez de critères d'acceptation pour être sans ambiguïté — mais ce n'est pas une spécification. Si une story demande une douzaine de critères ou ne tient pas dans un sprint, découpez-la. La story dit le quoi et le pourquoi ; l'équipe possède le comment.

Autres outils gratuits : générateur de PRD · calculateur RICE · WSJF · tous les outils