User Stories: Back to Basics

User story Agile

ou tout ce qui peut être utile à un apprenti Product Owner pour bien démarrer une partie importante de son activité:). Au programme:

  • Les « Basics » (définition, format User Voice, 3Ccritères INVEST)
  • Les gros + (Persona, Story Mapping,  Hypothéses & Mesures, Design Studio, Checklist, Découpage)

Les « Basics » des user stories

  • Rapide Définition d’une user story :

Une User story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur, source de VALEUR pour l’utilisateur ou le client final.

Les User Stories sont généralement regroupées au sein d’un Backlog de produit, dont elles constituent les items.

  • Format « User Voice »

En tant que  < Rôle d’utilisateur > ou < Persona >,
Je veux  < But >,
Si bien que  < Bénéfice : valeur crée / pb résolu >

Sous ce format, le rôle représente celui qui fait l’action et qui en bénéficie, le but représente l’action accomplie, La valeur Business représente les bénéfices qui se dégagent de l’action, en somme la raison d’être de cette User Story (troisième ingrédient de la formule que beaucoup à tort ont tendance à zapper…)

  • Règle des 3 C

Card: l’histoire est courte, une ou deux phrases et peut être écrite sur une carte 8×13 cm, c’est mieux

Conversation : les détails de l’histoire sont discutés par les équipes et avec le Product Owner en particulier

Confirmation :l’histoire est confirmée par les conditions de satisfaction et tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte) : c’est un élément majeur

  • Critères INVEST pour les user stories

I – Independent. Une bonne User Story est indépendante (des autres User Stories, bon autant que possible) notamment pour faciliter son traitement

N – Negotiable. Elle est négociée, discutée (c’est le second C, Conversation) dans des Backlog Refinement en amont des sprint, en Sprint Planning et tout au long du sprint

V – Valuable. Elle est source de valeur pour le Client final ou l‘utilisateur

E – Estimable. Elle est estimée par l’Equipe qui va la réaliser; une estimation relative c’est à dire les unes par rapport aux autres, en story points par exemple.

S – Size Appropriately. ou encore « Small enough » Suffisamment petite, elle peut être embarquée et livrée en 1 sprint

T – Testable. Une User Story est testable, notamment au travers des conditions de satisfaction et critères d’acceptation  (le troisième C, Confirmation). Si elle n’est pas testable ou vérifiable ce n’est pas une User Story.

Les + (niveau avancé)

  • PERSONAS.. pour réduire la Distance

« Un persona est un utilisateur-type, un ARCHETYPE, une représentation fictive des utilisateurs cibles, qu’on peut utiliser pour fixer des priorités et guider nos décisions de conception d’interface. »

Utiliser les Personas dans les User Stories (« En tant que Sophie ») est le prolongement naturel de la démarche.

Persona-User Story

Dans une dynamique empathique, cela permet de réduire la distance entre l’utilisateur final et l’Equipe de Dév, et de ne pas perdre de vue sa cible. Sur le plan opérationnel, cela permet aussi de fixer les priorités dans le Backlog de produit.

  • STORY MAPPING… pour des livraisons qui ont du sens en terme d’Usage
Résultat d'un Atelier StoryMap avec un Product Owner motivé
Résultat d’un Atelier StoryMap avec un Product Owner motivé

La Story Map en cartographiant les Stories selon deux axes (Séquence d’usage / Priorisation) va non seulement permettre d’initier le Backlog de Produit mais il va aussi favoriser le groupement et la livraison d’un ensemble de stories qui ont du sens pour un Utilisateur; des livraisons de sprint et le plus souvent de Release qui ont de la valeur et qui permettent à votre Persona d’atteindre ses objectifs les plus importants.

  • HYPOTHESES & MESURES…  pour s’assurer de produire des User Stories qui ont de la Valeur

Format Hypotheses Lean Startup

Les éléments de confirmation intègrent déjà des Conditions de satisfaction & Cas de Test qui permettront au PO ,en Revue de Sprint, de déclarer les Stories si les Stories sont DONE, c’est à dire Correctes et Complètes par rapport à ce qui a été demandé.

Ici, et il s’agit d’aller un cran plus loin, et d’intégrer au sein même des user Stories la boucle d’apprentissage chère au Lean Startup

Hypotheses-Mesure Lean Startup

Ce qui donnerait pour notre Persona Sophie, et cette User Story:

« En tant que Sophie, je veux voir les logos x, y et z ainsi qu’un petit cadenas sur la Home pour me rassurer sur mon inscription »

L’hypothèse suivante (à tester une fois que la story est livrée)

Nous croyons qu‘ajouter des logos xyz sur la Home va rassurer Sophie

Nous aurons raison si:

les logos sont positivement remarqués par n% des Utilisateurs (Tests Utilisateurs – Validation Intermédiaire) / si le nombre de signUp augmente de 30 % (Analytics validation finale)

Ce qu’on fait: Si OK on garde les Logos…on en ajoute potentiellement ailleurs (à tester)

  • DESIGN STUDIO…  pour amplifier les éléments de conversation et donner du sens

Le Design Studio est une activité de conception, du Sketching, menée de manière collaborative, en plusieurs temps dans une logique Divergence / Convergence pour donner du sens aux User Stories.

Sketching: Round 1 Travail individuel
Sketching: Round 1 Travail individuel

L’idée est ici de travailler ENSEMBLE les élements de conversation de la User Story: Design d’interface – Architecture de l’information, ingrédients essentiels (mais pas suffisants) pour garantir une bonne Experience Utilisateur. Ces Design Studio ont lieu le plus souvent au démarrage des projets et peuvent se faire aussi au cours d’un Backlog Refinement sur des User Stories spécifiques, pour s’assurer que celles-ci seront PRÊTES au démarrage du Sprint Suivant.

  • CHECKLIST.. pour ne rien oublier

La checklist doit être envisagée comme un guide de conversation et non comme un énième format de spécification !

User Story CheckList
User Story CheckList

Elle permet aussi d’identifier les éléments qui donneront du sens à la story et favoriseront sa compréhension, sa réalisation et sa confirmation. La partie haute et les premiers éléments sont initiés le plus souvent par le PO; le reste se construit dans un mode « Juste à temps – Juste ce qu’il faut » de manière collaborative avec l’Equipe.

  • DECOUPAGE… pour avoir des Stories suffisamment Petites

Le découpage de User Stories est une question de stratégies; en voici 10.

Par étapes d’un Workflow: L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémental.1 story par étape.

Par scenario: On a par exemple une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’autres pour les cas d’erreurs ou les scénarios alternatifs.

Par séquence dans un scénario: Le cas est plus précis, on découpe cette fois-ci une séquence au sein d’un scénario…

Par opérations: Souvent le plus évident en s’appuyant sur les CRUD (create, Retrieve, Update, Delete)  ; il peut être utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer.

Par format ou type de données: Assez  simple aussi. On joue sur le type d’objet (ex : compte titres, espèces… messages en français, anglais, espagnol…)

Par type d’entrée, sortie ou configuration : Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi  au niveau de l’interface…

Par Persona ou rôle: Décomposition sur la base de celui qui va utiliser le produit, le fameux « en tant que… ». S’appuyer sur la Story Map est vivement conseillée :).

Par niveau de connaissance: Le niveau de connaissance acquis sur une fonctionnalité est un bon critère de décomposition…Une story pour ce qui est connu, une autre là où c’est moins maîtrisé. Çela peut déboucher sur un spike (une user story un peu particulière orientée exploration)

Par niveau de complexité : Une user story va par rexemple décrire une fonctionnalité dans son mode de réalisation le plus simple, d’autres suivront par un niveau de complexité plus grand

Par niveau de qualité attendu: Performance, Sécurité, Utilisabilité… ces exigences non fonctionnelles constituent le plus souvent des conditions de satisfaction pour des user stories spécifiques mais elles peuvent permettent également de distinguer des user stories entre elles (ex : afficher en moins de 60 sec, moins de 30 sec ; données en temps réels ou non…)

Voilà, je crois qu’on est bon, là 🙂 Dispo pour en parler chez vous et / ou en conférences.

Votre feedback est le bienvenu

A propos de jc-Qualitystreet (Jean Claude Grosjean) 448 Articles
Jean Claude GROSJEAN - COACH d’Organisation. Coach d'Equipes - Coach Agile. J’accompagne la transformation des organisations et coach les PERSONNES, les EQUIPES dans leur nouveau parcours. La facilitation & la formation font aussi partie de mes activités. Me contacter: 06.20.98.58.40