Spécifications
Ce que reçoit votre équipe : des tickets prêts à développer.
Voici un exemple de user story, rédigée comme je les rédige pour mes clients. Un besoin exprimé en réunion devient un épic, puis des user stories, puis des tickets qui portent chacun leurs critères d'acceptation. Un développeur qui ouvre le ticket sait quoi construire et comment vérifier qu'il a terminé.
User storyPRD-142Exemple
En tant que responsable d'exploitation, je veux exporter les demandes clients du mois, afin de préparer le point mensuel sans ressaisie.
Critères d'acceptation
- Étant donné un mois sélectionné, quand je lance l'export, alors le fichier contient toutes les demandes de la période.
- Quand aucune demande n'existe sur la période, un message l'indique et aucun fichier vide n'est produit.
- L'export ne contient que les demandes que l'utilisateur a le droit de voir.
Hors périmètre
Export PDF, envoi automatique par e-mail.
- La spécification
- Le document de référence du projet : le problème, les utilisateurs, ce qui est inclus et ce qui ne l'est pas. Rédigée dans Linear, l'outil de suivi de projet, à côté des tickets qui la mettent en œuvre.
- L'épic
- Un ensemble cohérent de fonctionnalités, rattaché à un objectif. Il sert à prioriser et à suivre l'avancement sans se perdre dans le détail des tickets.
- La user story
- Un besoin formulé du point de vue de la personne qui l'a : qui, quoi, pourquoi. Chaque fonctionnalité doit pouvoir s'y rattacher à un usage réel.
- Les critères d'acceptation
- Les conditions vérifiables qui disent qu'un ticket est terminé. Les développeurs s'en servent pour construire, les testeurs pour vérifier, et vous pour valider.