🎯 Intention

La fonctionnalité est l’interface de communication entre le PO et les développeurs. Quand elle est bien spécifiée, on observe

Moins de questions de la part des développeurs, par conséquent moins d’interruptions du PO
Moins d’incompréhension, et donc moins de travail à refaire après développement.

On cherche donc le meilleur compromis entre :

précision ⇒ le développeur a tout ce qu’il faut pour travailler en autonomie et produire la fonctionnalité qui répond au problème.
concision ⇒ le brief est facile à produire pour le Product Owner et n’est pas trop long à lire

<aside> ✅ Pré-requis

✅ Points clés

<aside> ℹ️ Structure minimale d’un brief

</aside>

Point clé	Raison
**⛰️ Rattacher à son Epic
Q: Dans quel contexte s’inscrit la demande ? Quel est le problème plus haut niveau?**	Pouvoir suivre l’avancée de l’Epic
**⭐️ Enjeux
Q : Pourquoi on fait ça ? Quel est le gain ?
Ex: Décrire le contexte, donner l’objectif qu’on cherche à atteindre**	En comprenant le contexte, le développeur comprend mieux la demande et fait les bons arbitrages.
**🎯 Résultat à atteindre
Q: Comment on va valider ?
Ex: Les critères de succès de la fonctionnalité, les uses-cases qui seront testés pour valider**	Se mettre explicitement d’accord sur ce qu’on implémente et teste à la fin. On cherche à bien définir les cas-limites.
**📁 Ressources
Q: Qu’est-ce qui est nécessaire pour produire ?
Ex: images, textes, traductions, liens, maquette, etc**	On cherche à réduire au maximum les questions du type “Où se trouve XXX?” et “Quel texte je met dans le bouton ?”.
**✨ Inclure une visualisation du changement souhaité
Q: Où va-t-on voir un changement
Ex: screenshot, croquis, maquette figma**	Éviter les erreurs d’incompréhension qu’il peut y avoir lieu s’il n’y a que du texte

Oublier des cas limites à tester
Omettre les conditions d’affichage de certains éléments Exemple de rework (EVA-581) :

Ici, on a oublié de gérer le cas où il n’y a aucune évaluation incomplète. Dans ce cas, la légende ne doit pas être affichée, mais elle l’a été lors du développement, ce qui a entraîné un retour.
Recopier les règles métier sans comprendre finement les enjeux (ex: le client m’a dit alors j’ai recopié, même si je ne sais pas pourquoi il en a besoin). Le risque est ici est de compliqué inutilement le travail du développeur en lui donnant des contraintes inutiles.
Ne pas expliciter ce qui est ok. Exemple “Les articles de la facture sont les bons” → on ne sait pas ce que veut dire “bon”. À la place on veut mettre ici “Les dénominations des articles de la facture sont ceux de la référence fournisseur”