Une User story est une exigence du système à développer, une brève description d’une fonctionnalité telle que vue par l’utilisateur ; très en vogue sur les projets agiles. Dalleurs je n’utilise quasiment plus que ça.
« En tant que Client, je veux réserver un billet de train pour me rendre à Paris »
Quand on pense aux User Stories, on pense d’abord à la règle des 3C et aux critères de qualité (INVEST) et au format « User Voice »…
Nouveau ! Découvrez nos services de transformation agile en Suisse ainsi que nos activités de coaching agile / facilitation générative à Genève et Lausanne
Chaque user story sera estimée et priorisée mais ce qui caractérise aussi une user story, c’est qu’elle doit être SUFFISAMMENT PETITE pour être livrée dans un sprint (généralement les équipes embarquent au minimum 3 stories par sprint) . Une véritable nécessité si on veut observer de vrais gains en termes de valeur produite, de visibilité, d’avancement, de flexibilité, de feedback et d’amélioration continue.
Au cours de mes missions de coaching agile, je suis donc régulièrement amené à aider l’Equipe et le Product Owner à décomposer des user stories en user stories plus petites.
Voilà les 10 stratégies de décomposition que je propose, toutes efficaces et éprouvées !
1 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.
2 Par scenario
On obtient 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 :quand il se passe x ; quand il se passe y
3 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…
4 Par opérations
Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer.
5 Par format ou type de données
Assez évident aussi. On joue sur le type d’objet (ex : compte titres, espèces… messages en français, anglais, espagnol…)
6 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…
7 Par Persona ou rôle
Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’appuyer le story mapping, une activité menée au début du !projet pour définir le backlog de produit et la roadmap produit. Une approche trés orientée Agile UX – Lean UX
8 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)
9 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
10 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…)
Les illustrations viendront au fur et à mesure ; si vous voulez participer, n’hésitez pas à proposer votre exemple en commentaires avec le n° de stratégie correspondant… un post incrémental et participatif en quelque sorte.
Vous recherchez un coach disponible à Paris ou à Genève pour vous accompagner dans votre transformation? Découvrez mon profil et mes disponibilités.
En quoi puis-je vous aider?
Je m’appelle Jean Claude GROSJEAN. J’accompagne les personnes, les équipes, les organisations dans leur projet de transformation. Si la Gestion de produit Agile vous questionne, n’hésitez pas à me contacter, je peux vous accompagner…
Salut Jean-Claude,
Il y a aussi par critères d’acceptance et utilisation du SMART, normalement utilisé pour les tâches.
Dans une approche Acceptance Test Driven,
chaque critère pouvant devenir lui même une user story à part entière. Cela aide aussi pour l’indépendance, le I de INVEST, et forcément le T.
Mike Cohn encourage a adopté l’approche « slice the cake », qui vise à « découper le long du workflow »
Ex : une recherche d’article sur un site de vente en ligne
Etapes : saisir la recherche, afficher les resultats, consulter le détail d’un article
« Slice the cake » visera à découper des stories de telle sorte que chacune ira d’un bout à l’autre du workflow mais en manipulant seulement qqs données et/ou en satisfaisant à un sous-ensemble de critères d’acceptation
Mais cela suppose que le dev est suffisamment avancé pour pouvoir réaliser un « slice » en qqs jours !