Rédigez de belles user stories

Structurez vos user stories

Sur ce sujet, l’idée à garder en tête est :
« Le seul bon format d’une user story est celui qui fonctionne avec votre équipe ».

C’est normalement l’équipe qui sait ce dont elle a besoin pour commencer à
travailler. C’est elle qui va pouvoir dire si une user story est prête ou non, et ce quel que soit son formalisme.
Cependant, il existe une structure générique des user stories que vous pouvez utiliser comme modèle ou simplement comme source d’inspiration.

Généralement, une user story se compose :

• d’un titre : « Client détenteur d’une carte VISA règle sa commande ».
• d’une phrase narrative le plus souvent structurée sous la forme « En tant que … je veux … afin de… ». Par exemple : « En tant que client détenteur d’une carte VISA, je veux saisir mes données bancaires afin de régler ma commande avec ma carte VISA ». Cette formulation permet au Product Owner d’apporter une vision orientée client et d’identifier précisément la fonctionnalité et le bénéfice attendu.
• d’un ensemble d’exigences et de critères d’acceptation : « Contrôle à effectuer sur le format de carte ».

Dans certaines équipes, la user story réduite à son stricte minimum suffira,
dans d’autres, la user story ressemblera à une mini spécification. En la matière, nous constatons régulièrement que la longueur d’une user story peut refléter la distance qui sépare l’équipe de son Product Owner. Néanmoins, toute user story doit dans son ensemble respecter certains critères d’éligibilité. Il est possible d’utiliser le framework INVEST pour juger de la qualité d’une user story.

Selon ce framework, une bonne user story est :
I – Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres user stories induisent des problématiques de testabilité et de planification.
N – Négociable : elle doit amener à la discussion et peut-être modifiée jusqu’à son inclusion dans une itération.
V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la user story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur.
E – Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer.
S – Small : elle doit être de taille assez petite pour prioriser de façon sûre et
éviter les effets tunnels. Essayez donc au maximum de découper finement vos user stories.
T – Testable : la user story doit raconter une histoire, dont les tests découlent de façon évidente.

Attention ! Dans la pratique, il est très compliqué d’avoir un backlog totalement INVEST. Par exemple, il existera nécessairement des stories dépendantes entre elles que vous serez obligés de traiter les unes à la suite des autres. Cette méthode permet surtout au Product Owner de questionner son découpage et le contenu de ses user stories. C’est donc d’avantage une ligne de conduite qu’une règle immuable.

Une bonne user story ne doit pas présupposer de la solution. Cette dernière
sera construite par le Product Owner, l’équipe, le client au travers d’un dialogue autour de la compréhension du besoin et des options possibles.

De plus,

• n’hésitez pas à abuser des maquettes, schémas, mock-up, etc. : une image vaut mille mots.
• ayez en tête qu’une user story (indépendamment de son format) est avant tout une histoire qui se raconte, crée la discussion et amène l’équipe à confirmer sa compréhension du besoin.

Pour finir, la vraie question à se poser est : qu’est-ce qui fonctionne pour notre équipe ? Dans la mesure du possible, évitez le dogme, écrivez les user stories dont l’équipe a besoin pour développer, ni plus, ni moins, et demandez régulièrement à l’équipe ce qui peut être amélioré.

Mettez en place des critères d’acceptation : atelier “three amigos”

Les critères d’acceptation permettent de valider une user story. Ils vont guider les développeurs et testeurs pendant son développement ; il est donc important que ces tests soient partagés et compris par toute l’équipe. L’atelier “three amigos” aide à l’écriture des critères d’acceptation sous la forme de BDD (Behaviour Driven Developement).

Comment cela fonctionne ?

Un atelier “three amigos” réunit le Product Owner, un développeur et un ntesteur (s’il est différent du Product Owner). La participation d’un testeur n’est pas un impératif, mais peut être utile pour s’assurer que toutes les parties prenantes de l’intégration sont alignées sur les résultats attendus.

Avant l’atelier, le Product Owner écrit les exigences des différentes user stories qui seront traitées et les fait relire aux autres participants. Ainsi, le développeur et le testeur arriveront avec une liste de questions déjà préparée.

Une fois que les éléments devant être développés sont bien compris par tout
le monde, on reprend les exigences et liste ce qui devra être testé. Il n’est pas utile d’avoir un plan de test global, il faut juste se concentrer sur les principaux scénarios et la manière de les tester (test manuel, test unitaire, etc.).

Ce qui sort de l’atelier

Ce qui résulte de cet atelier est une liste de tests d’acceptation (souvent associés aux pratiques du BDD). Ils peuvent être écrits sous la forme :

• GIVEN… (un contexte)
• WHEN… (l’utilisateur effectue certaines actions)
• THEN… (ce que l’on observe)

Cette mise en forme sera faite après l’atelier, généralement par le testeur ou le Product Owner, avant d’être revue par tout le monde. La syntaxe utilisée,
appelée désormais langage Gherkin, est de plus en plus reconnue par des frameworks (tels que jBehave ou Cucumber) permettant d’automatiser ces tests fonctionnels.

Dans le cas d’une utilisation avec ce type de framework, il vous faudra être vigilant sur le niveau de lecture : il ne s’agit pas d’écrire un test générique, mais bien de l’exprimer avec des données précises.

En reprenant la user story proposée plus haut, un des cas de test pourrait s’exprimer ainsi :

Étant donné un utilisateur avec une carte de n°1234567890, valide jusqu’en 01/16 et de code sécurité 123,

Quand il saisit la carte 1234567890
Et la date de validité 01/16
Et le code de sécurité 123,

Alors, le paiement est accepté
Et il est redirigé vers la page de confirmation du
paiement.

La liste des tests d’acceptance n’est pas le seul point bénéfique de l’atelier, bien au contraire. La vision de ce qui va être développé est maintenant commune et bien partagée par tout le monde (testeurs compris). Les risques d’aller-retour au sein de l’équipe sont alors considérablement réduits.

Attention à ne pas en abuser !

Il est important de faire preuve de bon sens avant de proposer cet atelier. Il
n’est pas nécessaire de réunir trois personnes pour définir les tests d’acceptance d’une fonctionnalité basique et encore moins d’une correction d’anomalie (on sait déjà ce qui ne fonctionne pas !). Il est en revanche crucial, au moins au début d’un projet, de mettre d’accord les différentes personnes impliquées dans la réalisation d’une story sur la façon d’écrire cette dernière. Cela limitera a posteriori les incompréhensions entre ces acteurs.
Il ne faut pas perdre de vue que l’objectif est avant tout de sortir son produit rapidement… et non de générer de la documentation à tout va !