Origines de "User story" : Extreme Programming “XP” (1998), Agilité
Définition d'une User Story
Une User Story (“récit utilisateur” en français) est la description fonctionnelle utilisée dans les méthodes agiles. L'objectif est de spécifier le développement d’une fonctionnalité. Elle doit alors exprimer à qui elle s’adresse et en quoi elle apporte de la valeur.
Elle est généralement rédigée par le Product Manager, afin de définir un besoin auprès des équipes de développement, selon une structure qui permet d’exprimer de manière atomique (voir : INVEST), systématique et claire l’intérêt de la fonctionnalité.
Différents modèles de formulation existent ; en général, dans le cadre d’un projet, les Product Managers vont s’accorder sur un « template » clair et partagé. Ce dernier inclut les dimensions « qui », « quoi » et « pourquoi » :
En tant que <qui>, je veux <quoi> afin de <pourquoi>.
L’intérêt du <pourquoi> est d’exprimer clairement la valeur de la User Story pour l’utilisateur ; ce qui permettra notamment de les prioriser par ordre d’importance
Le <qui> ne désigne pas forcément un type d’utilisateur final du système, mais tout rôle concerné par le produit : utilisateur final d’un certain segment, testeur, développeur, administrateur, etc.
Les User Stories, sous leur format anglo-saxon, se présentent souvent sous deux formes :
As a <define the profile of the user>, I want to <describe the feature> so that <describe the value>
In order to <describe the value>, as a <define the profile of the user>, I want to <describe the feature>
Cette deuxième formulation obligeant le Product Manager à commencer par définir la valeur de sa story et évitant plus facilement que la première l’écueil consistant à répéter le <quoi> dans le <pourquoi>
Exemples de User Stories :
- As a MacOS Power User, I want to be able to see the size of all folders ; so that I can be more efficient when cleaning up my hard drive.
- Or, as an iPhone User, I want to get delivery reports for my outgoing SMS so that I can know when my friends have received my SMS.
- As a fraud detection manager, I want to prevent users from creating more than 5 accounts from the same android devices so that we can limit the number of fraudulent promotions we give.
User Story et Story Mapping
La User Story dépasse souvent le cadre de la simple phrase, et peut s’inscrire dans un groupe plus large de User Stories constituant un ensemble cohérent (voir : Epic). L’organisation globale de telles fonctionnalités constitue un « Story Mapping », permettant d’agencer de manière cohérente de nombreuses User Stories plus atomiques, et de les assembler en sous-ensembles permettant de discerner des fonctionnalités cohérentes : les Minimum Marketable Features.
Une User Story est souvent complétée par une description des règles de gestions ; idéalement co-rédigées entre le Product Manager, le Design et l’équipe de développement. Plus largement, le Product Manager peut y ajouter tous les éléments qui vont permettre à l’équipe de développement de prendre en charge l’implémentation complète de la fonctionnalité ; comme par exemple :
- Les critères d’acceptance ou « business rules »
- La documentation des wireframes / maquettes et autres éléments graphiques de l’interface utilisateur
- Les critères de succès ou « KPIs » à suivre pour mesurer par la suite la valeur de la User Story
- Les tests d’acceptance (au format BDD par exemple : voir BDD et Gherkin) pour valider de manière objective et systématique si la User Story a été implémentée correctement
Pour aller plus loin : Télécharger notre livre Les Clés du Product Management
