Il était une fois une Userstory
Qu’est-ce qu’une Userstory ?
La Userstory raconte l’histoire d’un utilisateur. C’est une demande fonctionnelle écrite de façon à mettre en avant les besoins utilisateurs. Elle est écrite dans un langage courant et compris par l’ensemble des intervenants du projet (Métier, développeur, testeur).
L’écriture d’une user story a un format stricte et cela afin que toutes les user-stories puissent suivent les mêmes règles.
La préparation d’une Userstory ?
Elle ne peut se créer d’un coup de baguette magique. Tout un travail en amont est effectué avant d’aboutir à son écriture:
Différentes étapes nécessaires
Ne vous lancez pas directement dans une Userstory sans avoir maturé de façon collaborative avec l’équipe et le Métier et priorisé votre sujet.
- La maturation de l’Epopée (ou EPIC en anglais) avec :
Le recueil des problèmes remontés par l’utilisateur final ou le Métier (qui deviendront des besoins),
Un découpage en fonctionnalités (équivalentes à des Minimum Marketable Feature ou MMF),
Une priorisation des besoins avec le Métier,
Atelier préconisé : le Story Mapping.
- Une phase de maturation des fonctionnalités avec :
Le découpage d’un besoin (MMF) en différentes Userstories,
Atelier préconisé : L’Event Modeling.
- L’écriture d’une Userstory
Atelier préconisé : L’Example Mapping.
Comment rédiger sa Userstory ?
Il n’est pas toujours aisé au départ de bien rédiger sa user story surtout lorsque certaines applications ne s’y prêtent pas.
Voici des questions à se poser en écrivant ses user-stories.
1 — Ai-je analysé un problème avec mon Métier et non une solution ?
2 — Ai-je trouvé le bon Persona ?
3 — Ai-je bien écrit le contexte dans lequel la Userstory s’inscrit ?
4 — Ma Userstory a-t-elle un titre compréhensible de tous ?
5 — Répond-elle à la règle des 3C avant le 3 Amigos ?
6 — Ai-je bien séparé la notion d’UX du besoin fonctionnel ?
7 — Une taille de T-shirt ? Une suite de Fibonacci ? Ou pas de point d’effort ?
Parler plus de “problème”, moins de “besoin” et pas de “solution” avec le Métier
Fréquemment, notre Métier arrive le plus souvent avec une liste de besoins. Mais avant de traiter leurs besoins, pourquoi ne pas commencer, pendant nos interviews, par leur demander quels sont leurs problèmes ? Il est difficile de parler de ce mot, car il est très souvent associé à une fatalité ou un obstacle.
Mais, finalement, si nous renversions cette situation ?
“Un problème bien posé est à demi résolu.” — Albert Einstein
Indiquons-leur plutôt qu’il s’agit d’une occasion de les écouter, de comprendre ce qui ne fonctionne pas, dans le but de leur apporter une amélioration.
Comme vous le savez surement, ceci correspond à une approche Design Thinking, et fait partie d’une des 5 étapes majeures: Empathize.
Le but de cette étape est de reformuler la problématique et de concrétiser le besoin. C’est à cette condition que les solutions apportées pourront être pertinentes.
Par des sessions de brainstorming, après avoir énoncé le problème en session, nous commencerons par poser des questions courtes. Ces questions seront le point de départ pour générer des solutions au problème qui seront … qui sait innovantes !!!
Définir le bon utilisateur clé : le Persona
L’écriture d’une Userstory commence toujours par le :
En tant que [persona],
Définir le bon utilisateur de la Userstory est important pour savoir si le besoin formulé est réel ou non, et si l’on est capable de le restituer au développeur et testeur.
“En tant que Internaute Prospect qui suis sur le point d’acheter une voiture,
Je veux consulter le tarif Auto”
Mais ce n’est pas toujours simple. Nous sommes très souvent tentés de ne pas l’indiquer car nous ne savons pas toujours qui sera l’utilisateur final du besoin ou bien parce que l’on fait intervenir des intermédiaires (le métier, par exemple).
Evitons :
“En tant que Service internet XXX,
Je veux envoyer un lead pour informer un Agent qu’un Prospect souhaite être contacté”
Préférons :
“En tant qu’Internaute Prospect qui suis sur le point d’acheter une voiture,
Je veux être contacté par un Agent Général
Afin de recevoir un tarif personnalisé pour un contrat Auto”
N’hésitez pas à personnaliser le Persona pour éviter d’avoir à écrire un texte à rallonge.
Evitons :
“En tant qu’Internaute Prospect qui suis sur le point d’acheter une voiture,
Je veux être contacté par un Agent Général
Afin de recevoir un tarif personnalisé pour un contrat Auto”
Préférons :
“En tant que Charlie Sheen,
Je veux être contacté par un Agent Général
Afin de recevoir un tarif personnalisé pour un contrat Auto”
Pour en savoir plus : Le Persona dans toute sa splendeur | by Silvere Duval | Jun, 2022 | Medium
Ecrire le contexte dans lequel la Userstory s’inscrit
En quelques mots, indiquer le contexte du sujet, avec
- Ce qui est fait actuellement,
- Ce que l’on souhaite faire,
- Où se positionne la Userstory dans le besoin global de la fonctionnalité (MMF).
Titre de la Userstory
En tant que …
Je veux …
Afin de …Contexte :
Une Userstory avec un titre compréhensible
Avoir un titre compréhensible permet de :
- Lire rapidement le besoin de la Userstory dans la MMF et le Kanban en résumant le Persona et le contexte,
- De pouvoir présenter la liste des Userstories, et donc des besoins inclus dans la MMF au Métier.
Pas la peine d’indiquer un numéro de priorité dans le titre d’une Userstory, nos outils (exemple : JIRA) ont tout ce qu’il faut pour le définir.
Evitons :
Titre US : “US 1 — Envoi d’un Lead devis”
Préférons :
Titre US : “L’internaute Prospect souhaite être contacté par un Agent Général pour recevoir un devis”
Ecrire les différentes règles avec la préparation des exemples pour le 3 Amigos
En premier lieu, il s’agit d’écrire une ou plusieurs règles cohérentes entre elles, associées au même besoin. Il suffira d’un titre court, dans une écriture courante et compréhensible de tous les intervenants du projet. Le descriptif de cette règle sera porté par les exemples.
Lors de l’écriture des règles, n’oubliez pas 4 points essentiels :
1 — Ne pas ajouter de négation dans une règle
Le but est de simplifier la tâche du développeur et du testeur et d’éviter de revenir vous voir, suite aux 3 Amigos, pour vous poser des questions suite au 3 Amigos pour lever l’ambiguïté du “Tout sauf”.
Evitons :
Règle : L’internaute ne peut pas consulter de tarif s’il est un client ==> Cela laisse une ambiguïté et des questions risquent de se poser : “Alors, qui peut consulter un tarif ? Un Prospect ? Un autre type d’utilisateur ?”
Préférons :
Règle : L’internaute consulte un tarif uniquement s’il est Prospect ==> pas d’ambiguïté : cela ne concerne que le Prospect.
2 — Ne pas indiquer d’information technique dans la règle, ni de notion d’UX (“cliquer sur un bouton” etc.)
Il s’agit bien de retranscrire le besoin fonctionnel et non d’orienter vers une solution technique ou d’UX. S’il ne s’agit que d’un sujet technique, demandez-vous s’il ne s’agit pas plutôt d’une Technical Story.
Dans le doute, posez-vous la question :
“La règle que je viens d’écrire pourrait-elle toujours fonctionner si je migre d’un logiciel vers un autre ?”
Mais nous verrons ce sujet UX dans un paragraphe suivant.
3 — Une pensée pour les testeurs
Si une Userstory ne peut être testée, ce ne peut être une Userstory. D’autre part, lors de son écriture, pensez aussi à la complexité de test. N’oubliez pas qu’une Userstory simple fonctionnellement ou en développement peut être complexe ou très complexe à tester.
Pensez peut-être à découper les règles en pensant à la simplification des tests, et cela même avant les 3 Amigos.
Un conseil : n’hésitez pas à écrire des Exemples avant le 3 Amigos mais ne les présentez pas au développeur et au testeur dès le début des 3 Amigos, car sinon, vous risquez de passer d’un atelier collaboratif à un atelier d’écoute.
- Cela vous permettra de :
Vérifier que vous avez bien pris en compte tous les aspects du besoin,
Vérifier que le développeur et le testeur ont bien compris,
- Cela vous aidera aussi à expliquer vos règles pendant le 3 Amigos.
Pour écrire les exemples, vous pouvez les écrire en Gherkin (Given / When / Then). Un tableau est aussi très efficace pour présenter les exemples dans la Userstory.
Par exemple :
4 — Soyons précis dans nos exemples
Cela permettra de clarifier les cas limites et vous éviter des allers/retours incessants avec votre développeur ou testeur.
Vous pourrez aussi les écrire avec des outils collaboratifs (tels que Draft.io, Miro, etc) et de copier l’écran dans votre Userstory.
Pour aller plus loin : Les 6 principes d’écriture d’une Userstory | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
Séparons l’UX de nos règles fonctionnelles
En écrivant une Userstory, pensez à ce que le besoin fonctionnel pourra être mis en place dans n’importe quel outil.
Cela veut dire quel que soit l’outil, le besoin sera le même. En revanche, la solution technique (à savoir l’affichage du texte, de boutons, d’image …) pourra être différente.
Imaginez la différence d’affichage entre un site Web et un écran mainframe, alors que, finalement, le besoin sera le même (Exemple : “Valider une fiche de coordonnées” pourra se faire via un bouton “Valider” ou une zone à renseigner par “O” + ENTER).
Prenons un exemple :
Evitons :
Règle : L’utilisateur appuie sur le bouton “Demande de contact” pour valider sa demande de contacte.
Préférons :
Règle : L’utilisateur demande à être contacté par un Agent Général
Given : L’internaute Prospect consulte le tarif Auto
When : Il demande à être contacté par un Agent en cliquant sur le bouton “Demande de contact”
Then : Envoi d’un lead à l’agent
— — — — — — — — — — — — — — — — — — — —
UX : Ajouter un bouton “Demande de contact” bleu, en bas à droite de l’écran (Cf. maquette d’écran jointe dans la carte sur Jira)
Pour aller plus loin : Comment j’écris les règles d’UX dans ma Userstory ? | by Silvere Duval | Jun, 2022 | Medium
Une taille de T-shirt ? Une suite de Fibonacci ?
C’est un sujet à part entière, car la taille d’une Userstory peut varier :
- En fonction de la maturité des équipes,
- Dans le temps, dès l’écriture d’une Userstory jusqu’à son développement et sa mise en Production.
Nous privilégions de ne pas utiliser de taille de Tshirt ou de Storypoints, mais plutôt le nombre de Userstories car l’équipe aura déjà préparé et découpé collectivement pour avoir des Userstories en moyenne équivalentes, dès les ateliers de maturation (Story Mapping, Event Modeling …).
Pour en savoir plus : Rien ne sert d’estimer, il faut partir à point | by Silvere Duval | Just-Tech-IT | Jun, 2022 | Medium
Votre Userstory est-elle prête à passer en 3 Amigos ?
Vous avez terminé l’écriture de votre Userstory. Avant de passer en 3 Amigos, demandez-vous si elle répond à ces critères :
La règle des 3 C
Card : Une Userstory courte
Conversation : Une Userstory discutée entre les équipes (Métier, UX, PM, PO, Dev, Test …)
Confirmation : Une Userstory confirmée par des tests d’acceptation rédigés dans la Userstory
La règle INVEST
I — Independent. Une User Story indépendante des autres User Stories notamment pour faciliter son développement
N — Negociable. Négociée, discutée dés les réunions d’estimation et de planification de la version
V — Valuable. Source de valeur pour le Client final ou l‘utilisateur
E — Estimable. Estimée par les équipes de développement. Cette estimation doit être faite en fonction des autres Userstory déjà terminées.
S — Size Appropriately. Le plus souvent petite car susceptible d’être traitée (livrée et testée) par la squad rapidement. Elle pourra être redécoupée pour avoir une taille plus appropriée.
T — Testable. Testable, avec des critères d’acceptation rédigés. Une Userstory non testable ou vérifiable, n’est pas une User Story.
N’oubliez pas que la Userstory est vivante jusqu’au 3 Amigos. Après avoir passé les 3 Amigos, les règles ne doivent surtout plus bouger, sinon, cela risque de rallonger le temps de développement, de pair-test.
Il faut donc que la Userstory ait bien été maturée et soit écrite clairement pour éviter toute remise en question des règles, pendant les développements ou tests.
Pour en savoir plus : Une Userstory indépendante. Dans cet article, nous allons vous… | by Silvere Duval | Jun, 2022 | Medium
Et après sa mise en Production ?
N’hésitez pas à créer une page dans le logiciel de travail collaboratif de votre société, en ajoutant régulièrement les nouvelles fonctionnalités, le lien vers la Userstory qui a été développée. Ou encore mieux : avoir une documentation vivante au plus proche de votre développement !
