Agilité: 10 stratégies pour avoir des User Stories suffisamment petites

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 »

User Story INVESTed... dans un format orienté But Utilisateur tourné vers la valeur

User Story INVESTed... dans un format orienté But Utilisateur tourné vers la valeur

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 user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit.

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

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

Follow Me:
TwitterLinkedIn

2 thoughts on “Agilité: 10 stratégies pour avoir des User Stories suffisamment petites

  1. 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.

  2. 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 !

Comments are closed.