Plusieurs sujets posent un vrai problème sur le terrain. Vouloir les ignorer ou rester dogmatique, ce n’est pas la bonne attitude et les problèmes surgissent. Peut-on les clarifier ?
US INVEST : quelle signification ?
Une User Story doit être INVEST, dit-on. Que signifie cet acronyme ?
- I : Indépendance de réalisation des US.
- N : Négociable, c’est-à-dire que son contenu peut être ajusté par le “backlog refinement”. Nous allons donner des exemples ci-après.
- V : Une US a une valeur pour le métier. Ce point ne sera pas traité dans cette série d’articles. Disons que l’on reconnaît une valeur à chaque US puisque le PO reconnaît son utilité (l’US n’est pas technique). Rappelons, cependant, que l’US est associée à une épopée qui elle-même à une valeur pour le métier. C’est même, pour le PO, LA seule valeur reconnue … L’US n’est en effet qu’un élément de réalisation de l’épopée. La valeur attendue comme un tout par les utilisateurs est celle de l’épopée !
- E : Estimable. Comme le point précédent, nous envisagerons une série d’articles consacrée aux caractéristiques de planification d’une US. Pour l’instant, sans entrer dans le détail des techniques et principes, nous comprenons intuitivement le sens du E d’INVEST : l’effort lié à chaque US doit pouvoir être appréhendé. Nous pourrons voir ultérieurement que cette obligation est, là encore, sujet à discussion.
- S : Small. Une US doit être réalisée en un sprint.
- T : Testable. Une US doit pouvoir être vérifiée pour elle-même, par des tests dédiés.
US INVEST : une US est-elle toujours indépendante des autres US ?
Nous ne détaillerons pas ici les possibilités d’affinage d’une épopée en US. Observons simplement, qu’in fine, les techniques utilisées nous amènent à deux types de résultat :
- Un “affinage par les données”
L’épopée est respectée de bout en bout, mais l’utilisateur sera contraint par les données utilisées. Par exemple, considérons l’épopée “En tant que client particulier, je veux pouvoir consulter mes opérations bancaires afin de contrôler mes comptes”. Elle fait partie du parcours client “utilisation du site internet pour les particuliers” dédié au cas d’usage “particuliers”.
Elle pourra donner lieu à plusieurs US, selon les types d’opérations effectuées. Par exemple :
- En tant que client particulier, je veux pouvoir consulter mes opérations en crédit”
- En tant que client particulier, je veux pouvoir consulter mes opérations en débit
Si cela n’est pas suffisant, on peut poursuivre la décomposition (et donc la “négociation” entre IT et métier). Pour illustrer, je pourrais traiter le sujet du débit en exploitant la donnée “type d’opération de débit effectuée” :
- En tant que client particulier, je veux pouvoir consulter mes retraits DAB
- En tant que client particulier, je veux pouvoir consulter mes prélèvements
- En tant client particulier, je veux pouvoir consulter mes virements
- …
Cette approche est intéressante car elle satisfait le client progressivement. Chaque US respecte l’objectif initial de consultation souhaité par l’utilisateur.
On peut modéliser, en restant simple, l’épopée affinée de la manière suivante :
Dans ce cas, les US internes à l’épopée sont bien indépendantes. Pour autant, bien entendu, je ne pourrais consulter que si, fonctionnellement, je peux accéder à l’écran d’accueil qui me permet de lancer cette consultation. Autrement dit, il y a toujours des dépendances entre une US et d’autres US précédentes !
- Un “affinage par les étapes de l’épopée”
Le traitement à réaliser peut se décomposer comme une suite d’étapes. On peut alors parfois satisfaire l’utilisateur par “petits bouts”.
Exemple : La consultation précédente est en fait décomposable en :
- Présentation “brute” des opérations par date et qui ont été contrôlées comme OK
- Possibilité de trier les opérations
- Possibilité de filtrer des opérations
- Possibilité de voir les opérations à problème (scénario d’utilisation avec contrôle KO).
Si on modélise l’épopée on a alors :
Le schéma montre bien que fonctionnellement les US sont dépendantes. Certes je peux tester l’US2 pour elle-même, mais il me faudra passer par l’US1 pour la lancer. On peut aussi techniquement commencer par réaliser l’US2 … mais quel intérêt ? On peut affirmer, que les US ont des événements déclencheurs et des résultats parfaitement définis, permettant, du point de vue technique, de les réaliser séparément. Mais on rappelle, qu’une US doit avoir un sens métier, capable d’être utilisée et fournir à l’utilisateur un service qu’il attend. D’où une remarque INVEST sur leur indépendance qui fait beaucoup grincer des dents les PO … avec raison ! Pourquoi maintenir cette affirmation qui peut être sujet à autant de controverses ?
Quant à l’idée de découper techniquement une épopée (appelée encore “découpage horizontal”), ce principe est possible, voire parfois nécessaire. Cependant le résultat ne répond plus à une logique métier. Vaut mieux alors créer des “technical stories”.
On retiendra donc que, malgré les efforts de la plupart des influenceurs de la communauté agile, la notion d’indépendance peut, parfois, être contestée et qu’il ne faut pas considérer le “I” de INVEST comme un dogme.
Comment alors classer les corrections de spécifications ?
Lorsque l’équipe agile s’attaque à un nouveau sujet, le PO définit des épopées, puis toute l’équipe définit ensemble des US pour les décomposer si les épopées ne peuvent tenir en un sprint. Prenons un exemple, pour les sprints SP14, 15 et 16 des US sont imaginées et suivent les critères INVEST.
Mais un détail peut ne pas convenir aux utilisateurs après quelques semaines d’utilisation, ou bien l’épopée peut être améliorée. Comme en théorie l’US a été fermée, donc il faudra créer, pour les développeurs, une autre US.
Une US doit être rattachée à une épopée. Cela implique que si l’épopée a aussi été jugée terminée, il y aura nécessité de créer dans l’outil de pilotage de la réalisation une autre épopée !
Comment ces modifications agiles doivent-elles être gérées dans les sprints à venir (SP 24 et SP25) ?
Sur le terrain nous voyons deux approches :
- Mise en place d’un type de ticket “correction de spécification”
Cette décision est, selon nous, la plus saine, même si la littérature agile, le plus souvent, n’en parle pas. Autant le type « bug » est bien identifié par les équipes, autant la correction microscopique de spécification (sous-entendu, la spécification d’une exigence interne à une US qui aurait dû apparaître dès l’US créée) n’a pas la même reconnaissance officielle. Le PO et les utilisateurs ne sont pourtant pas omniscients. Les changements (par exemple, une évolution du contexte métier) doivent être aussi admis.
Nous parlons ici de corrections microscopiques. On peut aussi appeler les types de tickets “correction d’US” pour insister sur le fait que leur énoncé aurait dû être encapsulé dans une US précédente. Un tel élément de réalisation n’est pas une US INVEST, donc peut très bien ne pas avoir une valeur métier suffisante. … Est-ce que changer une taille de police ou la couleur d’un texte mérite la création d’US ? Comme en physique, on tombe dans un monde de particules (et un monde d’atomes) qui, même compris de l’utilisateur, n’a pas la taille suffisante pour être cataloguée comme US.
Précisons qu’une grande évolution de spécification peut être de type epic et donner lieu à des US nouvelles et des tickets de correction d’US.
- Utilisation d’US
Le ticket ne répond pourtant pas aux critères INVEST : on n’a, par exemple, plus rien à négocier, ou encore la valeur métier n’a pas grand sens.
C’est donc, à notre avis, une mauvaise décision (que l’on rencontre pourtant souvent …).
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
