Les users stories

Les user stories sont l’un des outils de base utilisés par les équipes de projet Scrum et eXtreme Programming (XP). Il s’agit de la définition grossière d’une expression de besoin, contenant juste assez d’informations pour permettre aux développeurs de produire une estimation raisonnable des efforts déployés pour la mettre en œuvre.

Vision simplifiée des user stories

Pour comprendre l’utilité des user stories, il faut imaginer une note récapitulant la conversation initiale lors de laquelle le client a exprimé son besoin. La demande exprimée doit pouvoir être comprise en une simple phrase.

Cela pourrait être aussi simple que ces exemples :

• « Les factures sont téléchargeables depuis le compte utilisateur. »
• « Les professeurs peuvent saisir les notes des étudiants. »
• « Les cartes de stationnement peuvent être payées via PayPal. »

Formalisation des user stories

Format d'écriture

Les user stories ont été formalisées avec un format du type :

• En tant que (rôle),
• je veux (but à atteindre),
• afin que (bénéfice).

Grâce à cette formalisation, les aspects cruciaux de la demande sont explicites. Cela est positif aussi bien lors des phases de conception que pendant le développement.

Pour reprendre les exemples précédents, cela donnerait :

• « En tant qu'utilisateur du site, je veux pouvoir télécharger mes factures depuis mon compte utilisateur, afin de les avoir en local sur mon ordinateur. »
• « En tant que professeur, je veux pouvoir saisir les notes des étudiants, afin que l’administration y ait accès. »
• « En tant qu’automobiliste qui se gare, je veux pouvoir acheter une carte de stationnement en payant avec mon compte Paypal, afin de pouvoir le faire même sans moyen de paiement à disposition. »

Identifiant unique

Idéalement, une user story est identifiée par un label unique. Cet identifiant est souvent numérique (nombre qui s'incrémente à chaque nouvelle user story), mais l'important est qu'il soit unique, reconnaissable et sans ambiguïté. Il est utile si vous devez faire un lien entre une user story et d’autres documents, qu'il s'agisse d'autres user stories citées en références, des spécifications, des documentations, des tests d’acceptation...

Indicateur de priorité

Il faut toujours indiquer la priorité d'une user story. Elle peut être exprimée de plusieurs manières différentes :

• >Numérique, avec un nombre de 1 à 10 qui peut être croissant (10 désignant la plus grande priorité) ou décroissant (1 correspondant à la plus grande priorité) en fonction des habitudes de travail dans l’entreprise.
• >Textuel, avec un label définissant le niveau de priorité (“basse”, “moyenne”, “haute”, “urgente”) ou le degré de nécessité (en anglais “must”, “should”, “could”, “won’t”).

Cette information sera utilisée par les parties prenantes pour prioriser les user stories les unes par rapport aux autres.

Estimation de coût

Il faut indiquer une estimation >imprécise du coût du projet. L’important est de donner une indication concernant l’effort nécessaire à la mise en œuvre de la user story. Cette indication peut porter sur :

• >la durée, exprimée en jours, semaines ou mois
• >l’aspect financier, dont la valeur est exprimée en euros, en dollars...
• d’autres méthodes d’estimation comme les >points de complexité (dans le cadre d’une méthodologie agile)

Cette estimation pourra être affinée au cours de la vie du projet. Le but est de permettre aux parties prenantes de s’assurer que le coût du projet est en phase avec sa valeur intrinsèque.

Point à prendre en compte

Les user stories sont écrites par les « clients » du projet

Les user stories doivent être rédigées par les parties prenantes fonctionnelles du projet (ou leurs représentants tels que les propriétaires de produits), et non aux développeurs. Les user stories sont assez simples et se rédigent en quelques minutes. Pour plus d’efficacité, il est donc logique qu’il revienne aux experts du domaine de les rédiger.

Utiliser des outils simples

Les user stories sont généralement rédigés sur des fiches (physiques ou virtuelles). Privilégiez un moyen qui permettra à tous les membres de l’équipe d’y accéder facilement, ainsi qu'aux documents éventuellement associés.

Planification et implémentation des user stories

La planification

Pour obtenir une planification de qualité, les user stories doivent être traitées par ordre de priorité. Le travail sera donc effectué dans l’ordre défini dans la liste des user stories en attente de traitement.
Les parties prenantes du projet sont responsables de la priorisation des user stories : en utilisant leurs indicateurs de priorité, elles sont triées dans la pile des tâches en attentes (aussi appelée « backlog »).

Les parties prenantes peuvent définir de nouvelles user stories, changer d’avis sur les stories existantes et même de redéfinir les priorités à leur guise. Mais il est important que les user stories ne soient pas modifiées pendant qu’elles sont utilisées pour réaliser un travail ; dit autrement, une user story ne doit pas évoluer pendant qu’un développeur travaille dessus.

Les parties prenantes sont également responsables de la prise de décision et de la fourniture d’informations complémentaires en temps voulu.

L’estimation

Les développeurs sont responsables de l’estimation des efforts requis pour mettre en œuvre les éléments sur lesquels ils vont travailler. Étant donné que vous ne pouvez effectuer qu’une quantité finie de travail durant une itération, la taille des user stories affecte le moment durant lequel elles seront traitées.

Les développeurs doivent donc être consultés lorsque sont estimés les coûts liés aux user stories (que ces coûts soient calculés en points de complexité, en jours, en euros ou toute autre unité).

La réalisation

Une user story doit :

• pouvoir être réalisée par la personne qui en a la charge,
• sur la durée d’une itération.

Ainsi, si vous avez des itérations (ou sprints) d’une semaine, vos user stories doivent être définies en conséquence. Si vous pratiquez la programmation en binôme (ou pair programming), chaque user story doit pouvoir être implémentée par un binôme en une itération.

Dernier point à prendre en compte, une user story ne sera souvent pas suffisante pour mener a bien un développement. C’est une manière pratique et facilement compréhensible d’illustrer un besoin, mais qui nécessite souvent plus d’informations. On prendra alors soin de lier la user story à un ou plusieurs documents (spécification fonctionnelle, maquettes, spécifications techniques…) qui contiendront toutes les données nécessaires.

Epics

Lorsqu’une user story est trop importante pour que sa réalisation soit faisable en une itération, elle doit être découpée en plusieurs user stories plus courtes. La story initiale sera appelée une epic (parfois traduit « épopée » en français).

Le plus souvent, les epics correspondent à des user stories qui ont une priorité basse ; plus leur priorité remontera, plus on fera l’effort de les découper en user stories plus précises.