User Story

Origines de « User story » : Extreme Programming “XP” (1998), Agilité

Une User Story (“récit utilisateur” en français) est la description fonctionnelle utilisée dans les méthodes agiles pour spécifier le développement d’une fonctionnalité, en exprimant à qui elle s’adresse et en quoi elle apporte de la valeur.

Elle est généralement rédigée par le Product Owner, 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 Owners vont s’accorder sur un « template » clair et partagé qui 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 Owner à 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:

  • 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.
  • 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.

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 Owner, le Design et l’équipe de développement. Plus largement,  le Product Owner 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

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *