Créer des user stories
Transformer une spécification en stories que les développeurs peuvent construire.
Vous avez un PRD ou une description de fonctionnalité et vous devez le décomposer en user stories suffisamment petites pour être implémentées dans un sprint, suffisamment claires pour que les développeurs n'aient pas à deviner, et suffisamment testables pour que l'assurance qualité sache quand c'est terminé.
Modèle de prompt
Vous êtes un chef de produit expérimenté qui décompose une fonctionnalité en user stories pour l'équipe technique.
Voici la fonctionnalité ou le cahier des charges à décomposer :
<contexte>
$ARGUMENTS
</contexte>
> Si le champ ci-dessus est vide, demandez à l'utilisateur : "{{COLLEZ VOTRE PRD, DESCRIPTION DE FONCTIONNALITÉ, LIENS DE DESIGN, OU EXIGENCES APPROXIMATIVES ICI}}"
Décomposez cette fonctionnalité en user stories en utilisant la structure suivante pour chacune :
**Titre :** Nom court et descriptif pour la story
**Récit :** En tant que [rôle utilisateur spécifique], je veux [action], afin de [bénéfice/résultat].
**Critères d'acceptation :**
- [ ] Étant donné [précondition], quand [action], alors [résultat attendu]
- [ ] Inclure les cas limites, les états d'erreur et les conditions aux limites
- [ ] 4 à 6 critères par story — suffisamment pour être clairs, pas au point d'être une mini-spécification
**Priorité :** P0 (indispensable pour le lancement), P1 (devrait être fait), ou P2 (agréable à avoir / futur)
**Remarques :** Dépendances, références de design, considérations techniques, ou questions ouvertes.
Appliquez ces principes :
- Chaque story doit pouvoir être terminée en un seul sprint. Si elle est trop volumineuse, divisez-la.
- Les stories doivent être indépendantes — évitez les chaînes où la story B ne peut pas commencer avant que la story A soit livrée.
- Rédigez les critères d'acceptation comme des comportements testables, pas des descriptions vagues. "L'utilisateur voit un message de succès" pas "l'utilisateur a une bonne expérience."
- Incluez les chemins non heureux. Que se passe-t-il quand l'API échoue ? Quand l'utilisateur n'a pas de données ? Quand il atteint une limite de débit ?
- Regroupez les stories par flux de travail utilisateur, pas par composant technique.
- Signalez toute story qui nécessite une contribution design, des changements d'API, ou des dépendances inter-équipes.
Conseils
- Donnez à cela la sortie de craft-spec pour un pipeline propre PRD → user stories.
- Si les stories continuent à sortir trop volumineuses, le cahier des charges a probablement un périmètre qui devrait d'abord être divisé en phases.
- Les meilleurs critères d'acceptation ressemblent à un script de test — un ingénieur QA doit pouvoir vérifier chacun d'eux sans poser de questions.
- N'oubliez pas la story "état zéro" — que voit l'utilisateur avant d'avoir des données ? C'est presque toujours oublié.