User story agile

Qu’est ce qu’une user story agile ? Cet article va répertorier l’ensemble des articles que nous avons écrit sur les user-stories agiles afin de vous simplifier le travail.

J’en profiterai pour vous donner quelques exemples de user-stories et quelques astuces complémentaires. Je remarque aujourd’hui, qu’il n’est pas toujours simple pour les nouveaux Product Owner de bien saisir comment écrire les user-stories.

Vous pouvez regarder la vidéo de la minute agile sur le sujet :

Une user story agile

Une user story est une demande fonctionnelle écrite de façon à mettre en avant les besoins utilisateurs. Elle est écrite dans un langage naturel compris par l’ensemble des acteurs du projet ou liés à celui-ci.

Pour écrire une user story agile, on suit en fait un format stricte pour que toutes les user-stories suivent les mêmes règles. Le format suivant est celui que l’on rencontre dans 90% des cas :

En tant que [persona], je souhaite [souhait] afin de [but]
As a <persona>, I want <goal/desire> so that <benefit>

Exemple de user stories agiles

Voici quelques exemples de user-stories sur un site e-commerce :

• En tant que client je souhaite ajouter un produit dans mon panier
• (et) En tant que client je souhaite payer en carte bleue
• (ou) En tant que client je souhaite recevoir mon produit en point relais

Rédiger sa user story à partir d’une demande SMART

Il est intéressant de partir d’une demande SMART pour écrire ses user-stories. Vous pouvez aller voir l’article ci-dessous pour avoir plus d’information mais une demande SMART doit être spécifique, mesurable, achevable, pertinente et timeboxable.

Article : CRÉER SES USER-STORIES À PARTIR DE DEMANDES SMART

Rédiger sa user story agile

Il n’est pas toujours simple au départ de bien rédiger sa user story surtout dans certaines applications complexes. Voici des questions à se poser en écrivant ses user-stories.

1/ Quel est vraiment le besoin  ?

Même si cela peut paraitre simple dans un grand nombre de cas, il n’est pas toujours si évident de définir l’utilisateur clé qui a le besoin. Pourquoi ?

Il n’est pas rare dans les entreprises que les demandes soient écrites par des « métiers » qui ne connaissent pas réellement leurs utilisateurs. Ils font des demandes en pensant bien faire… Mais parfois le besoin n’est pas réel.

Du coup le Product Owner qui est un intermédiaire supplémentaire n’a aucune information sur le besoin réel voire peut avoir une vision erronée de celui-ci.

Savoir que le « client final » est l’utilisateur de la user story ci-dessous semble facile à deviner :

"En tant que client, je souhaite ajouter un produit au 
panier"

Mais ce ne sera pas toujours aussi simple… Partons sur un exemple de user story plus complexe cette fois.

"En tant que logisticien, je souhaite cliquer sur un bouton 
pour indiquer qu'une commande est livrée"

Si cette user story agile semble bien écrite au premier abord, elle n’est probablement pas correcte en réalité ; un logisticien a t il réellement un besoin de cliquer sur un bouton ? Cela ressemble plutôt à une action requise pour répondre à un besoin.

Voici la user story qui présente le besoin réel qui se cache derrière cette demande  :

"En tant que client, je souhaite être informé que ma 
commande va être livrée afin de pouvoir la réceptionner"

En effet, c’est le client qui a le réel besoin d’être informé de la livraison du produit et non pas le logisticien qui a le besoin de cliquer sur un bouton. C’est tendancieux, je vous l’accorde, mais c’est très important de bien comprendre le besoin initial pour savoir y répondre au mieux.

Se focaliser sur le logisticien dans ce cas risque de nous faire oublier que c’est surtout sur le client qu’il faut se focaliser et de ne pas faire une fonctionnalité parfaite pour le client.

L’utilisation de « En tant que » n’est pas suffisant dans l’écriture d’une user story ; il est impératif de bien cerner le besoin réel de l’utilisateur clé comme vous pouvez le constater.

2/ Ma user story agile est-elle bien INVEST ?

Une user story doit vraiment être INVEST pour être de bonne qualité :

• I pour indépendante des autres user-stories (au moins sur le sprint de prise en charge)
• N pour négociable (entre les différents acteurs et intervenants),
• V pour qui propose de la valeur pour les utilisateurs clés
• E pour estimable
• S pour suffisamment petite (de façon à être développable en 1 sprint)
• T pour testable.

Voici un article qui traire du sujet que vous pouvez lire pour approfondir ce sujet.

Article : QU’EST-CE UNE USER STORY INVEST ?

Voici un article également pour bien comprendre comment découper ses user-stories afin qu’elles soient suffisamment petites comme le conseille l’INVEST.

Article : COMMENT DÉCOUPER SES USER-STORY ?

Pour conclure sur la user story agile

Avec cet article sur la user story, vous devriez mieux comprendre comment créer les user-stories et surtout les bonnes questions à se poser lorsque vous allez travailler dessus.

Je vous propose d’aller plus loin encore sur le sujet grâce à cet article que j’avais écrit qui propose d’aller plus loin encore sur le sujet (voir ci-dessous). Si le « En tant que… » est la base de la user-story, il vous faudra la compléter par d’autres éléments indispensables.

Article : COMMENT BIEN CRÉER SES USER-STORIES ?

Mauvaise orthographe : userstory – user-storie – user stories agile – user story scrum