User Stories trop grosses : Comment bien les découper ?

Comment bien découper les User Stories ?

23 février 2021

Dans tous les projets agiles du monde, les US sont toujours trop grosses !

Jamais trop petites !

Comment bien découper les User Stories pour atteindre la granularité voulue ?

Granularité des User Stories

Selon la théorie agile, on définit la granularité acceptable d’une US lorsque l’implémentation technique de cette dernière peut être réalisée dans une itération (Sprint en Scrum).

On peut donc se dire :

« Si mon US passe dans un Sprint, c’est bon ! »

« Si elle ne passe pas, je la découpe… »

Mais est-ce réellement suffisant ?

Etudions par exemple ce graphique d’avancement (Burdown Chart) :

Graphique d’avancement (burdown) avec de grosses User Stories

Même si le Sprint se termine bien puisque toutes les US sont finies le dernier jour du Sprint, on peut quand même déclarer que les US sont ici trop grosses :

  • Nécessité d’attendre les tout derniers jours du Sprint pour savoir si le Sprint est un succès. Il ne faut pas être cardiaque !
  • Le Product Owner, qui doit valider l’implémentation sur la base des critères d’acceptation, se voit obligé de tout faire à la fin du Sprint.
  • Idem pour les testeurs fonctionnels.
  • Au moindre imprévu, c’est tout le Sprint qui échoue puisqu’aucune US ne sera terminée.

Même si chaque User Story est suffisamment petite pour être implémentée dans un Sprint, il apparait judicieux de travailler encore leur granularité.

Après tout, quels sont les risques d’avoir des US trop petites ?

  • Livraisons d’US tout au long du Sprint…
  • Pas d’embouteillage à la fin pour le Product Owner et les testeurs fonctionnels…
  • Meilleure visibilité tout au long du Sprint du travail de l’équipe…
  • En cas d’imprévu au milieu du Sprint par exemple, les US déjà terminées apporteront quand même de la valeur à ce Sprint
Bref, ce sont des « risques » que toute équipe agile aimerait bien prendre !!

Graphique d’avancement (burdown) avec de petites User Stories

Bien sûr, cela ne signifie pas qu’il ne faut avoir QUE des US de petite taille ! Mais engager dans un Sprint quelques US de granularité très fine permet de valider, tester et livrer en recette dès les premiers jours du Sprint. Et surtout de gommer un mini-effet tunnel qui ferait qu’aucun avancement n’est constaté pendant la première partie du Sprint.

Ok pour obtenir des US petites mais comment découper des US que l’on pense trop grosses ?

Technique du découpage vertical

On parle beaucoup du découpage vertical…

Il s’agit d’un découpage technique effectué selon les couches de l’architecture qui sont traversées. La raison principale est que ce ne sont pas les mêmes équipes qui travaillent sur ces différentes couches puisque les technologies sont différentes.

L’exemple typique est celui d’ajout de plusieurs champs dans un formulaire. Un découpage vertical et technique logique est de dire :

  • Une US pour le développement front (ajout graphique des champs dans l’écran du formulaire)
  • Une US pour le service web qui permettra de transmettre les données de ces champs entre l’écran et la base de données
  • Une US pour la base de données pour ajouter les champs voire créer une nouvelle table

Ce type de découpage n’est pas forcément à recommander pour plusieurs raisons.

D’abord parce qu’une User Story exprime un besoin du point de vue de l’utilisateur. Pas de notions techniques donc ! Ce n’est pas l’utilisateur final qui va réclamer un service web ou une nouvelle table dans la base de données. L’utilisateur, remplacé par le Product Owner ou la personne qui rédige l’US, va demander la possibilité d’une action avec le logiciel en attendant un résultat. Et c’est l’obtention de ce résultat pour l’utilisateur qui apportera de la valeur au produit.

Ensuite parce que ce principe de découpage purement technique contredit les bonnes pratiques de l’agile qui recommande des développeurs multi-compétences (fullstack). Le Product Owner, entre autres, n’a pas à prévoir que telle US pourra être prise en charge par un développeur frontend ou telle autre par un développeur backend. Il est nettement préférable de laisser l’équipe de réalisation gérer ce type de découpage au niveau des tâches techniques.

Découpage d’une User Story en tâches techniques

Le découpage vertical pour raisons techniques garde tout son intérêt mais au niveau de l’Epic (Epopée) ou de la Fonctionnalité. Pas au niveau de l’US.

Prenons l’exemple classique de l’application déclinée en web et mobile iOS et Android :

Fonctionnalité : En tant qu’abonné à l’option photos, je consulte les photos publiées dernièrement
US1 : En tant qu’abonné consultant les photos sur un phone Android, j’accède aux photos les plus récentes. US2 : En tant qu’abonné consultant les photos sur un phone Apple, j’accède aux photos les plus récentes. US3 : En tant qu’abonné consultant les photos sur un navigateur Chrome, j’accède aux photos les plus récentes.

On obtient bien un découpage vertical lié aux questions techniques. Mais on garde l’US sur des considérations fonctionnelles. On a tout simplement ici une US pour l’utilisateur Android, une US pour l’utilisateur iOS et une US pour l’utilisateur Chrome.

Technique du découpage selon le nombre de critères d’acceptation

La technique de découpage selon le nombre de critères d’acceptation part d’un constat très simple. S’il y a beaucoup de critères d’acceptation pour valider l’US, c’est que cette dernière est trop grosse !

Un critère d’acceptation est extrait pour devenir une nouvelle US… jusqu’à ce que chaque US possède un nombre de critères d’acceptation raisonnable.

Avant d’aborder cette technique diablement efficace, il faut bien sûr savoir rédiger de bons critères d’acceptation .

Prenons un exemple simple et concret : celui d’un formulaire de saisie d’une adresse de livraison.

Description et critères d’acceptation d’une User Story principale

On constate aisément que cette US est certainement trop grosse : elle comporte six critères d’acceptation et on devine que les critères n°4, n°5 et n°6 sont des sujets à part entière !

Il est pertinent ici de découper cette US en gardant les trois premiers critères d’acceptation. Cette US « allégée » sera néanmoins suffisante pour saisir une adresse secondaire de livraison. Nous sommes bien dans l’esprit de l’agile : délivrer de la valeur rapidement, quitte à améliorer par la suite. Les clients préfèreront certainement pouvoir saisir leur adresse secondaire de livraison dès la prochaine mise à jour de notre application plutôt qu’attendre de longues semaines pour avoir une fonctionnalité beaucoup plus aboutie.

Nous conservons donc l’US suivante que nous appellerons US n°1 :

Description et critères d’acceptation de la première User Story découpée

Puis nous créons une nouvelle US, l’US n°2, à partir du critère d’acceptation n°4 :

Description et critères d’acceptation de la deuxième User Story découpée

Même principe pour créer l’US n°3 à partir du critère d’acceptation n°5 :

Description et critères d’acceptation de la troisième User Story découpée

Et enfin, création de l’US n°4 à partir du critère d’acceptation n°6 :

Description et critères d’acceptation de la quatrième User Story découpée

Vous voyez comment, à partir d’une US manifestement trop grosse, nous avons obtenu quatre US en tout. Une US principale qui apportera rapidement de la valeur aux utilisateurs (ici, la possibilité de saisir une adresse secondaire de livraison) et trois US complémentaires qui viendront enrichir la fonctionnalité.

Itérations selon le nombre de critères d’acceptation

Le nombre de critères d’acceptation comme indication précieuse pour découper et affiner les récits utilisateur :

  • Un récit utilisateur possède n critères d’acceptation
  • Certains de ces n critères sont utilisés pour écrire de nouveaux récits utilisateur
  • Ces nouveaux récits nécessitent de nouveaux critères d’acceptation
  • On itère si de nouveaux récits contiennent au moins n critères d’acceptation…
à A chaque équipe, selon son projet, son contexte, ses habitudes de fixer la valeur de n.

A vous de jouer !!!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *