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 ?
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) :
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 :
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 ?
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 ?
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 :
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.
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.
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.
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 :
Puis nous créons une nouvelle US, l’US n°2, à partir du critère d’acceptation n°4 :
Même principe pour créer l’US n°3 à partir du critère d’acceptation n°5 :
Et enfin, création de l’US n°4 à partir du critère d’acceptation n°6 :
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é.
Le nombre de critères d’acceptation comme indication précieuse pour découper et affiner les récits utilisateur :
A vous de jouer !!!