Élaboration de stories
L'élaboration de stories ajoute à une story retenue pour une itération le détail, les exemples et les critères d'acceptation dont une équipe a besoin pour la construire et la démontrer. Elle se tient en atelier, au plus près de l'itération qui livrera la story, avec ceux qui l'exécuteront: les experts métier, le représentant du client, la personne qui la testera et le business analyst qui anime la séance. L'Agile Extension au guide BABOK la situe à l'horizon Livraison et la soumet à deux contraintes: juste à temps, juste assez. Son produit est une compréhension partagée de ce que « terminé » veut dire pour cette story.
Objectif
L'élaboration de stories définit le détail de conception et les critères d'acceptation d'une story, au niveau qu'exige la livraison d'une solution qui fonctionne. Elle porte sur une story à la fois. L'Agile Extension au guide BABOK en fait le dernier niveau de la décomposition.
La décomposition de stories décide combien il y a de stories et où chacune se range dans la hiérarchie. L'élaboration prend une story déjà taillée à la bonne mesure et la remplit. L'objet élaboré est le plus souvent une user story, parfois un cas d'utilisation ou une exigence détaillée portée sur le backlog.
Le §7.19.2 place la technique à l'horizon Livraison. Le tableau 7.0.1 la range dans la gestion des exigences et du côté des équipes internes.
Usage
Quand l'utiliser
- Story retenue pour l'itération à venir: l'élaborer dans les jours qui précèdent l'atelier de planification.
- Critères d'acceptation absents ou invérifiables: la séance les réécrit sous une forme que le testeur sait exécuter.
- Intention du client ambiguë: des exemples chiffrés tranchent ce qu'une formulation abstraite laisse ouvert.
- Règle métier à confirmer: l'expert qui la détient répond en séance.
- Détail écrit il y a plusieurs mois: reprendre la séance plutôt que se fier à un texte que la release a rendu caduc.
Quand ne pas l'utiliser
- Story trop grosse pour une itération: la rendre à la décomposition de stories avant d'y ajouter du détail.
- Story qui ne partira pas avant plusieurs itérations: l'affinement du backlog suffit jusque-là.
- Inconnue technique qui bloque toute réponse: un spike la lève avant que la séance ait matière à travailler.
Description
Qui est dans la salle
L'Agile Extension nomme quatre rôles: les experts métier qui détiennent la règle, le représentant du client qui a besoin de la story, la personne qui la testera et le business analyst qui anime la séance et met la story à l'épreuve. Les trois premiers apportent les trois angles sous lesquels une story se révèle incomplète: la règle, l'intention, la vérifiabilité. Three Amigos, terme de George Dinwiddie repris par l'Agile Alliance, désigne l'examen d'un élément de travail sous les perspectives métier, développement et test. Le guide n'inscrit pas de développeur dans sa liste: le §7.19 couvre deux de ces perspectives, le métier et le test, et le business analyst y occupe la place du développeur. En pratique, une séance dont personne ne sortira pour construire écrit des critères sans que quiconque y chiffre ce qu'ils coûteront.
Le business analyst y tient deux rôles. Animer, c'est tenir le sujet sur une story et arrêter la séance quand la réponse manque. Contester, c'est demander pour chaque critère comment il sera vérifié et sur quelle donnée. L'Agile Extension insiste: le praticien élabore et transmet sans cesse des exigences mouvantes, ce qui demande autant de facilitation que de communication.
Juste à temps, juste assez
L'élaboration ne porte que sur les stories retenues pour l'itération à venir. Elle se tient en préparation de l'atelier de planification, assez tôt pour que l'équipe estime sur du détail écrit. Le repère pratique est d'une itération d'avance.
Le guide énonce deux fautes de calendrier. Trop tôt: l'information vieillit, la release évolue autour d'elle et le détail doit être élicité de nouveau avant de servir. Trop tard: l'équipe attend son tour ou démarre sur une story dont les critères ne sont pas écrits, et la question se règle alors dans le code.
Le guide porte trois forces au crédit de la technique: moins de temps d'élicitation et moins de documentation, aucun détail produit pour une fonctionnalité qui aura changé avant d'être implémentée, une équipe qui reste sur la fonctionnalité la mieux classée du backlog.
Les critères d'acceptation
L'élaboration clarifie, ajoute ou retire des critères d'acceptation. Le format et la construction de ces mesures relèvent des critères d'acceptation et d'évaluation. Clarifier: un critère écrit en intention reçoit une valeur, un seuil ou une date. Ajouter: une question de l'expert métier découvre un cas que personne n'avait couvert. Retirer: un critère décrit une autre story ou prescrit une solution technique que l'équipe reste libre de choisir.
Chaque critère doit pouvoir être tranché par un test que le testeur sait écrire avant que la construction commence. La forme « Étant donné / Quand / Alors », que le behaviour-driven development a rendue courante, oblige à nommer l'état de départ, l'action et le résultat observable. Ron Jeffries en donnait la raison en 2001 en plaçant la confirmation à côté de la carte et de la conversation: ce dont on convient oralement se perd, sauf sous la forme d'un test que quelqu'un peut faire tourner.
Les éléments que la séance peut produire
Le guide énumère cinq sorties possibles. Chacune répond à une question restée ouverte.
| Élément | Ce qu'il tranche | Quand le produire |
|---|---|---|
| Définition et découpage des tâches | La façon dont l'équipe se répartit la construction de la story. | La story tient dans l'itération mais personne ne voit par où commencer. |
| Exemples et scénarios | L'intention du client, cas par cas, sur des valeurs concrètes. | Deux personnes dans la salle lisent le même critère différemment. |
| Modèles basse fidélité (modèle de données, diagramme de flux de données) | La structure des données ou leur cheminement entre les systèmes. | La story crée une entité nouvelle ou traverse plusieurs applications. |
| Maquette d'écran ou de rapport | Les champs affichés, leur ordre, les libellés, le chemin de validation. | La story se joue dans une interface que le client verra. |
| Tableau d'entrées et de sorties | Le contrat de données entre deux composants ou deux équipes. | Une autre équipe fournit la donnée ou la consomme. |
Le guide les donne pour optionnels. Produire les cinq sur chaque story est le signe que l'atelier a repris la spécification détaillée en amont que la démarche agile écarte.
Ce que l'atelier laisse derrière lui
Le résultat est une compréhension partagée, entre les parties prenantes, de ce qui doit être livré pour que la story atteigne l'état « terminé ». Les critères, les scénarios, la maquette et le tableau de données sont les traces écrites de cette conversation. Ils s'attachent à la story dans l'outil de backlog, où celui qui construit et celui qui teste les retrouvent. Un compte rendu séparé se désynchronise dès le premier changement de critère.
Ce qui fait échouer une élaboration
La story qu'il fallait rendre au découpage
La séance découvre qu'une story ne tient pas dans une itération. Le guide prévoit ce cas: l'élaboration identifie des occasions de décomposer. La conduite juste est de rendre la story à la décomposition et d'élaborer les morceaux quand ils seront retenus à leur tour. La faute courante est de continuer, puis de produire deux heures de détail sur une story découpée la semaine suivante.
Le niveau de détail mal jugé
Le guide reconnaît la difficulté sans la résoudre: trouver le niveau qui permette de développer, de tester et de comparer aux critères. Trop peu de détail: l'équipe invente la règle pendant la construction. Trop de détail: l'équipe suit une conception arrêtée par des gens qui ne construiront pas. On s'arrête quand le testeur sait écrire son test et quand celui qui construit n'a plus besoin d'une seconde conversation pour commencer.
La séance sans testeur
Le testeur est le seul dont le métier consiste à demander comment on saura. En son absence, les critères s'écrivent en intentions plausibles et la question de la vérification se pose en fin d'itération, quand la réponse coûte une reprise. C'est la personne la plus souvent sacrifiée au calendrier, parce qu'elle semble venir plus tard.
Considérations IA
Un modèle de langage travaille bien sur la mise en forme des sorties de la séance. À partir d'une story et de ses critères, il propose des scénarios « Étant donné / Quand / Alors » et énumère les cas qu'une salle sous contrainte de temps oublie: la valeur limite, la liste vide, la double soumission, l'annulation en cours de route. Il convertit aussi un jeu de critères en squelette de tableau d'entrées et de sorties, que la séance corrige au lieu de le construire.
L'élaboration est gouvernée par le juste assez, et un modèle produit trente scénarios au même coût que six. Une liste générée puis versée telle quelle sur la story rompt le juste assez: l'équipe passera son itération à satisfaire des cas que personne n'a demandés. La consigne utile impose un plafond et fait justifier chaque scénario par un critère.
La règle métier échappe au modèle. Qu'un appareil subventionné interdise de descendre sous un palier d'abonnement avant l'échéance du contrat est un fait contractuel que détient l'expert de la facturation. Un modèle interrogé là-dessus produira une règle vraisemblable, indiscernable d'une règle vraie par sa forme. Les maquettes et les tableaux de données portent des noms de champs et des enregistrements d'exemple souvent tirés de données réelles; la loi fédérale sur la protection des données (LPD) s'applique à cet extrait comme au reste.
Exemples
Un opérateur télécom suisse élabore la story retenue pour l'itération suivante: « En tant que client, je veux passer à un abonnement moins cher dès le prochain cycle de facturation, afin de cesser de payer des données que je n'utilise pas. » Elle arrive de la décomposition avec trois critères d'acceptation. La séance en ressort avec quatre scénarios, une maquette et un tableau de données.
| Scénario | Étant donné | Quand | Alors |
|---|---|---|---|
| Prise d'effet au cycle suivant | Un client à CHF 39 par mois dont le cycle de facturation s'achève le 30 avril | Il confirme le passage à CHF 29 par mois le 20 avril | L'abonnement à CHF 29 s'applique dès le 1er mai |
| Confirmation avant validation | Un client à CHF 39 par mois qui a choisi l'abonnement à CHF 29 | L'écran de confirmation s'affiche | Il porte les deux prix, l'économie mensuelle de CHF 10 et la date de prise d'effet |
| Second changement bloqué | Un changement déjà programmé pour le 1er mai | Le client demande un second changement avant cette date | Le service le refuse et affiche la date de prise d'effet du changement en cours |
| Aucune proration du cycle en cours (ajouté en séance) | Un cycle de facturation de 30 jours, du 1er au 30 avril | La facture d'avril est établie après une confirmation le 20 avril | Elle porte CHF 39, sans remboursement des 10 jours restants |
Le quatrième scénario est celui que la décomposition n'avait pas vu. L'expert de la facturation demande ce que devient le cycle en cours, et la séance arrête la règle: rien n'est restitué. Sur un cycle de 30 jours, une confirmation le 20 avril laisse 10 jours à l'ancien tarif. Une proration aurait crédité l'écart mensuel de CHF 10 au prorata de ces 10 jours, soit CHF 10 × 10 ÷ 30 = CHF 3.33 arrondis au centime. Ce montant n'est pas crédité: la facture d'avril reste à CHF 39.00 et le tarif de CHF 29.00 court dès le 1er mai. Le chiffre sert ici à mesurer ce que la règle écarte.
La maquette basse fidélité de l'écran de confirmation tient en quatre lignes et un bouton: abonnement actuel CHF 39.00, nouvel abonnement CHF 29.00, économie mensuelle CHF 10.00, prise d'effet le 1er mai. Le tableau d'entrées et de sorties fixe le contrat du service.
| Sens | Champ | Valeur d'exemple | Origine ou règle |
|---|---|---|---|
| Entrée | Identifiant de l'abonnement en cours | MOB-39 | Contrat du client |
| Entrée | Identifiant de l'abonnement visé | MOB-29 | Catalogue des abonnements éligibles |
| Entrée | Date de la demande | 20.04 | Horodatage du service |
| Entrée | Dernier jour du cycle en cours | 30.04 | Calendrier de facturation |
| Sortie | Date de prise d'effet | 01.05 | Premier jour du cycle suivant |
| Sortie | Économie mensuelle | CHF 10.00 | CHF 39.00 − CHF 29.00 |
| Sortie | Montant facturé pour le cycle en cours | CHF 39.00 | Tarif en cours, proration écartée |
| Sortie | Message de confirmation | « Votre abonnement passe à CHF 29.00 par mois le 1er mai. » | Gabarit portant la date de prise d'effet |
Visualisations
La technique se dessine en deux panneaux. À gauche, la story telle qu'elle sort de la décomposition: une carte portant sa seule phrase. À droite, la même story après la séance, entourée des éléments que l'atelier lui a attachés, les critères d'acceptation, les scénarios, la maquette et le tableau d'entrées et de sorties. Une flèche en tirets sort du second panneau, étiquetée du seul cas qui ne se règle pas dans la salle: la story trop grosse, rendue au découpage.
Le dessin porte l'invariant de la technique: la story garde son identité d'un panneau à l'autre, seul son détail croît. Un panneau de droite portant plusieurs cartes au lieu d'une seule dessinerait la décomposition.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible | La story et ses premiers critères existent; l'animateur relit la branche du backlog et convoque quatre personnes. |
| Exécution | Moyen | Une à deux heures par story, à répéter pour chaque story retenue à chaque itération. |
| Documentation | Faible | Critères, scénarios et maquettes s'attachent à la story dans l'outil de backlog; aucun document séparé à tenir. |
Outils
L'outil de gestion de backlog reçoit les sorties de la séance: un champ de critères d'acceptation sur la story, des sous-tâches pour le découpage, des pièces jointes pour la maquette. Les critères rangés dans un commentaire ou dans un document lié échappent aux vues d'équipe et à la définition de terminé.
Le tableau partagé, Miro, Mural ou un mur et des notes autocollantes, porte la séance: les exemples se déplacent, se regroupent et se jettent. Ce support convient à l'esquisse d'un modèle de données ou d'un flux, que la séance dessine pour trancher une question puis abandonne.
L'outil de maquettage basse fidélité, Balsamiq ou Figma en mode filaire, tient le rôle prévu par le guide. Une maquette trop aboutie déplace la conversation vers les couleurs et les espacements, quand la séance cherche les champs et les règles.
L'outil de scénarios exécutables, Cucumber, SpecFlow ou équivalent, prolonge la séance quand l'équipe pratique le behaviour-driven development: les scénarios écrits en atelier deviennent des tests qui tournent. Une équipe qui ne les exécute pas garde le même gabarit de rédaction sans l'outillage.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.19 Story Elaboration: l'objet de la technique, sa place à l'horizon Livraison, la tenue en atelier et la liste des rôles, la discipline du juste à temps et du juste assez, la préparation de l'atelier de planification, les éléments: l'élicitation, le renvoi à la décomposition, les critères d'acceptation et les cinq sorties optionnelles, ainsi que les forces et les limites énoncées, dont les deux fautes de calendrier et la difficulté de juger le niveau de détail.
- IIBA, Agile Extension to the BABOK Guide, §7.0, tableau 7.0.1 Selecting the Right Technique: la technique rangée parmi les techniques de gestion des exigences, du côté des équipes internes.
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation, XProgramming, 2001: la confirmation comme troisième composant d'une story, antérieure à la technique qu'elle éclaire sans la définir.
- Agile Alliance, What are the Three Amigos?: les trois perspectives métier, développement et test réunies sur un élément de travail, attribuées à George Dinwiddie.