Savoir rédiger une user story Agile est une des compétences clés de l’application de la méthode agile.
En savoir plus sur la méthode agile
En effet, la première grande différence qu’on remarque lorsqu’on souhaite adopter cette philosophie est l’approche vraiment centrée sur les utilisateurs.
L’attention n’est plus focalisée sur la conception, mais sur la création d’une valeur réelle pour les clients.
Les règles d’écriture des User stories sont strictes et doivent être respectées. Elles permettent de définir les avantages que votre produit apporte à ses utilisateurs.
Dans cet article nous verrons grâce à des exemples de user stories concrets, comment réussir à rédiger une user story Agile.
Vous trouverez aussi des templates à remplir ou pour vous inspirer lors des prochaines préparations de votre backlog.
Qu’est ce qu’une User Story ?
Une carte d’identité des fonctionnalités à développer
Les user stories (ou US) sont des descriptions d’exigences pour toutes fonctionnalités ou “tâches” nécessaires au fonctionnement du produit ou du service en développement.
Elle est écrite par le Product Owner de manière concise et ne concerne qu’une seule fonctionnalité à la fois.
Une fois rédigée, elle va s’ajouter aux autres user stories du produit et ensemble, elles constituent le “product backlog”.
Le product backlog est en quelque sorte un réservoir de fonctionnalités à développer dans les prochaines itérations.
Plus d’information sur le product backlog.
Dans cet article, nous nous concentrerons sur les user stories de l’approche Scrum mais pour Kanban, on utilise également ce concept de carte.
Découvrez la différence entre Scrum et Kanban
Pourquoi rédiger une user story Agile ?
Les user stories constituent un excellent moyen de définir votre produit avec clarté.
Des user stories bien définies et hiérarchisées peuvent vous aider à articuler les fonctionnalités de votre produit en utilisant un vocabulaire simple, sans détails techniques.
Aussi, la rédaction d’une user story génère des discussions importantes au sujet du produit.
Elle permet à la fois à l’équipe Scrum et aux parties prenantes externes de mettre en lumière les interrogations ou désaccords potentiels.
Les US aident à clarifier les équipes sur le “quoi” construire, pour “qui”, “pourquoi” et “quand”.
Elles aident aussi à la communication du projet en dehors de l’équipe. Souvent les développements des produits digitaux nécessitent un langage technique et complexe, impliquant beaucoup d’acronymes.
Les US permettent la participation de personnes non techniques au projet.
Mais quelles sont alors les règles d’écriture des user stories ?
Comment bien rédiger une user story Agile ?
La différence entre US, épics, tâches et bugs
Avant de créer votre carte de fonctionnalité, notamment si vous utilisez un software de management de projet Agile tel que Jira, il faut que vous définissiez si la carte est une user story, une épic, une tâche ou un bug.
Les épics, user stories et tâches sont différents niveaux de granularité.
Ajuster la granularité de son US permet de trier et ordonner les US dans son backlog.
- Une Epic est une macro-user story. Elle représente un objectif d’action pour l’utilisateur. Si une US ne peut être développée par un membre de l’équipe en une itération c’est qu’elle est trop complexe.
Cette us doit être transformée en Epic et celle-ci doit être re-découpée pour créer des user stories plus petites. - Une tâche est une action à réaliser parmi d’autres afin de pouvoir développer la user story.
Les membres d’une équipe Scrum trouvent souvent plus facile de découper les us en tâches techniques.
Le processus de décomposition d’une us en tâches aide également l’équipe de développement à mieux comprendre ce qui doit être fait.
Prenons un exemple simple d’application bancaire.
Si l’épic est l’ « authentification de l’utilisateur », alors les user stories sont:
- Écran de connexion utilisateur.
- Processus du Mot de passe oublié.
- Verrouiller le compte après trop de tentatives infructueuses.
Et les tâches de l’us « Écran de connexion utilisateur » sont:
- Conception de la page de connexion.
- Couper les icônes et les images SVG.
- Implémenter la page de connexion HTML / CSS / JS.
- Créer des scripts SQL pour créer des tables.
- Créer une API de service Web pour les informations utilisateurs
- etc…
Les bugs eux, sont des correctifs à apporter à une user story – développée, testée et rejetée – ou au produit en général suite à son mauvais fonctionnement.
Une fois que vous savez si vous devez créer un bug ou une US et son niveau de granularité, vous pouvez entamer le processus de rédaction.
Utilisez des Personas pour écrire une user story Agile
Une excellente technique pour vos user stories consiste à travailler avec des Personas.
Ce sont des personnages fictifs basés sur une connaissance profonde des utilisateurs de votre produit.
Pour vous familiariser avec vos utilisateurs, le persona représentatif doit être visuel.
Il se compose généralement :
- d’un nom
- d’une image
- de ses caractéristiques
- de ses comportements
- d’un objectif.
Son objectif doit représenter le problème que le personnage veut voir résolu en utilisant le produit.
Construire en équipe un Persona peut réellement aider à créer des épics et leurs user stories.
Reprenons l’exemple de l’application bancaire et un de ses Personas:
Template d’un Personna
Voici le template utilisé vide. N’hésitez pas à le télécharger !
Le modèle à suivre pour écrire une bonne user story
Une fois votre ou vos Personas créés, vous pouvez commencer à écrire vos us.
Elles doivent être concises et faciles à comprendre.
Il faut éviter les termes confus et ambigus et utiliser le présent.
Concentrez-vous sur ce qui est important pour le Persona concerné par votre US.
Pour cela, rédiger la user story en suivant le modèle “En tant que”, “je souhaite”, “afin de”.
Cette structure permet de poser les variables les plus importantes de la fonctionnalité : le Qui ? le Quoi ? et le pourquoi ?
En lisant une user story rédigée avec ce model, les développeurs ne peuvent pas faire de mauvaises interprétations. Les développements correspondront exactement aux exigences écrites.
En tant que <Persona>,
Je souhaite <quoi?>
afin que <pourquoi?>.
Reprenons l’exemple de notre application bancaire et de notre Persona pour rédiger une user story sur le processus du mot de passe oublié (Epic : Authentification utilisateur).
En tant que utilisateur XXX je souhaite pouvoir réinitialiser mon mot de passe oublié afin d’en recevoir un nouveau et d’accéder à mon espace personnel.
Respectez les critères INVEST
INVEST est simplement l’acronyme qui aide à retenir un ensemble de critères pour s’assurer de la qualité d’une user story.
Si votre us ne répond pas à l’un de ces critères, l’équipe peut vouloir la reformuler, ou même envisager une réécriture.
Une bonne user story doit être :
- Indépendante des autres user stories: elle doit pouvoir être développées indépendamment des autres us du backlog pour éviter les blocages et embouteillages dans le processus.
Si en prenant l’US, un développeur doit attendre qu’une autre US soit mise en production, elle va créer un goulot d’étranglement risquant un non respect de l’engagement pris en début de sprint.
- Négociable : elle doit être assez flexible pour permettre à l’équipe d’échanger et de discuter.
- D’une grande valeur pour l’utilisateur : pour chaque US développée et livrée en fin d’itération, une valeur ajoutée doit être apportée au client.
- Estimable : l’équipe Scrum doit toujours être en mesure de l’estimer lors de la cérémonie du sprint planning.
- Si l’équipe n’arrive pas à se mettre d’accord, la user story manque d’informations ou n’est pas suffisamment claire.
- D’une taille suffisamment petite (S pour Size) : une User Story est plus facile à estimer, à comprendre et à développer si son découpage est réussi.
- Testable : certains critères qui vont définir si une user story développée est considérée comme terminée. Lorsqu’un utilisateur ne peut tester une fonctionnalité cela pose une problématique.
Ajouter les critères d’acceptation
Une fois l’objectif de l’US rédigé il faut y ajouter des critères d’acceptation.
Ces critères vont compléter la user story et vous permettre de décrire les conditions à remplir pour que le développement soit un succès ou un échec..
Ce sont ces critères qui rendent un US testable et garantissent qu’elle peut être montrée aux utilisateurs et aux autres parties prenantes lors du sprint review.
Je vous conseille d’utiliser trois à cinq critères d’acceptation pour votre user story.
J’utilise aussi un certain model :
Etant donné que <situation>
Lorsque <action réalisée>
alors <résultats obtenus>
Si nous reprenons l’exemple de l’application bancaire et l’US sur le processus du mot de passe oublié :
Critères d’acceptation :
- Etant donné que je suis sur la page de connexion, lorsque je clique sur “mot de passe oublié” alors je suis redirigé vers la page de réinitialisation du mot de passe
- Etant donné que je suis sur la page “réinitialiser mon mot de passe”, lorsque je rentre et que je valide mon identifiant, alors une vérification de mon identifiant m’informe si il existe ou non.
- Etant donné que mon e-mail existe lorsque je valide mon identifiant, alors je reçois par sms mon nouveaux mot de passe.
Template de user story
Voici un template pour la rédaction d’une user story Agile
En conclusion
Les règles d’écriture pour rédiger une user story Agile n’ont plus de secrets pour vous !
Mais attention, la partie la plus importante de la création d’une US n’est pas visible car elle représente la communication avec l’équipe.
Il est très important que le Product Owner discute des US avec l’équipe et que vous les affiniez ensemble.
N’hésitez pas à me dire en commentaire si les templates vous ont été utiles ! S’ils vous plaisent je veillerai à en insérer dans les prochains articles.
