Fractionnement des user stories qui ne peuvent pas être intégrées dans un sprint

Diviser une user story consiste à scinder une story trop vaste en plusieurs stories plus petites, dont chacune apporte néanmoins quelque chose d’utilisable pour l’utilisateur. Une story que vous ne pouvez pas estimer est généralement une story que vous ne pouvez pas encore livrer — et la diviser est la démarche qui permet de la remettre sur le tableau.

La plupart des discussions du type « nous ne pouvons pas estimer cela » sont en réalité des discussions de décomposition déguisées. L’équipe n’est pas confrontée à un problème de chiffres ou d’effort ; elle est confrontée à un problème lié à un trop grand nombre d’inconnues. La décomposition réduit ces inconnues jusqu’à ce que l’histoire prenne la forme d’un travail déjà réalisé — et que les estimations convergent.

Quand faut-il cesser d’estimer et commencer à diviser ?

Une feature qui ne tient pas dans un sprint n’est pas un problème de taille, mais un problème de forme. Soyez attentifs aux signes suivants :

• L’équipe vote pour des valeurs de 13 et 20, puis continue à revoter pour parvenir à un consensus plutôt que de se diviser.
• « Ça dépend » répond à plusieurs de ces questions de précision.
• L’histoire s’étend au-delà du périmètre d’une seule équipe.
• Le statut « Terminé » nécessite plusieurs déploiements.
• Vous pouvez le décrire en deux phrases, mais pas en deux critères d’acceptation.

Si vous persévérez malgré tout, l’équipe passe le sprint à s’y essayer et reporte ce qui reste — ce qui est regrettable, car ce sont justement les tâches les plus difficiles qui sont reportées —, ou bien elle termine un sous-ensemble prêt à être livré et considère le travail comme achevé, tandis que le reste reste à moitié terminé. Ces deux options sont pires que de scinder délibérément le travail avant le début du sprint.

Pourquoi un écart important entre les votes signifie une division et non un nouveau scrutin

Lorsqu’une équipe de taille variable travaille ensemble en utilisant le planning poker, un écart important constitue le signal le plus utile qu’elle puisse produire. Des cartes réparties entre 3 et 13 ne traduisent pas un désaccord sur les chiffres. Il s’agit en réalité de deux scénarios qui se font passer pour un seul. La personne qui attribue un 3 envisage une portée ; celle qui attribue un 13 en envisage une autre. Un nouveau vote ne permettra pas de les concilier : le travail consiste à discuter pour déterminer quelle portée est la bonne. Voici ce qui se passe généralement en coulisses :

• Une personne évalue le scénario idéal ; une autre évalue les cas limites.
• L’un part du principe que le projet existe déjà ; l’autre part du principe qu’il est en train de le concevoir.
• Une personne évalue l’ampleur de la requête ; une autre évalue l’ampleur du déploiement.
• Une personne sait que cette dépendance existe ; une autre l’ignore.
• Une personne évalue les besoins d’une personne présente dans la salle ; ce travail relève d’une autre équipe.

Ajouter des détails ne résout que rarement le problème : cela ne fait qu’allonger le ticket, sans pour autant affiner l’estimation. En revanche, le fractionnement est efficace : en un pic si l’inconnue concerne la cause, en tranches verticales si l’inconnue concerne le périmètre. Le fait que deux cartes soient présentées ne signifie pas que l’équipe est en désaccord. Cela signifie que l’équipe vote sur des stories différentes. Renvoyez-le.

Coupez verticalement, et non horizontalement

La division doit être verticale — une fine tranche qui soit réellement livrable en soi — et non horizontale. « Backend d’abord, frontend au sprint suivant » divise l’histoire comme un couteau divise de la pâte : vous obtenez deux moitiés vides de sens. Une tranche verticale touche toutes les couches et permet de livrer une colonne fonctionnelle — un bouton qui fonctionne de bout en bout, même s’il ne gère qu’un seul cas de saisie. Voir tranchage horizontal vs vertical pour le principe dans son intégralité.

Des stratégies de fractionnement qui font leurs preuves

SPIDR — pic, chemin, interface, données, règles — couvre la plupart des cas de fractionnement, et c’est par là qu’il faut commencer. Quelques autres schémas reviennent suffisamment souvent pour mériter d’être mentionnés.

Étapes du processus

Une story qui couvre l’ensemble du parcours utilisateur — inscription, configuration des préférences, confirmation de l’adresse e-mail, consultation du tableau de bord — se divise souvent clairement en fonction des limites entre les différentes étapes. Lorsqu’elle fonctionne, c’est la technique la plus claire de la boîte à outils : chaque story apporte un élément reconnaissable et visible par l’utilisateur, chacune peut faire l’objet d’une démonstration, et chacune peut être définie de manière autonome.

Le test consiste en une seule question, posée à chaque étape : l’utilisateur en tirerait-il un avantage si nous lancions cette fonctionnalité sans rien d’autre ? « Définir les préférences » passe le test : un utilisateur ayant défini ses préférences, mais n’ayant pas reçu de confirmation par e-mail, peut toujours utiliser le service. « Envoyer le formulaire » échoue : un utilisateur dont l’envoi ne aboutit nulle part se retrouve dans une situation pire qu’auparavant. Si la réponse est non, l’étape est une sous-tâche, et non une « story », et le flux de travail ne se divise pas à cet endroit.

La version plus rapide du même test : chaque étape pourrait-elle être mise en production en trois sprints sans que rien d’autre ne change, tout en garantissant une expérience cohérente à chaque étape ? Si le fait de sauter une étape conduit l’utilisateur à se retrouver face à une page défectueuse, la segmentation est fausse. C’est le piège dans lequel tombent les équipes d’ingénieurs : les étapes correspondent à la manière dont le code se décompose (service d’authentification, API des préférences, composant du tableau de bord), elles semblent donc granulaires. Elles sont effectivement granulaires. Ce sont également des tranches horizontales sur lesquelles s’appuie le vocabulaire du workflow, et aucune d’entre elles ne fournit quoi que ce soit à l’utilisateur. Le signe révélateur : chaque « étape » relève de la responsabilité d’un seul spécialiste. Les véritables étapes du flux de travail traversent la pile, car c’est le cas des véritables étapes destinées à l’utilisateur.

Variations des règles métier

Une story comportant plusieurs règles ou rôles — utilisateur standard, administrateur, client API — est divisée par règle. Commencez par mettre en production la règle la plus courante ; les variantes suivront. Chaque variante constitue une véritable story avec ses propres utilisateurs.

Scénario favorable, puis scénario défavorable

Ce concept est étroitement lié à l’approche Path de SPIDR. Proposez d’abord le scénario idéal ; la gestion des erreurs, les tentatives de reprise et les cas limites viendront ensuite. L’utilisateur peut obtenir un résultat positif avant même que les modes de défaillance ne soient entièrement gérés — à condition que vous acceptiez un comportement de défaillance moins satisfaisant dans l’intervalle, et que vous reveniez effectivement sur ce point par la suite.

Qualité différée

Lancez la version sans les finitions — pas d’infobulles, pas d’animations, pas de modifications administratives — puis lancez les finitions dans le cadre d’une story distincte. Cela fonctionne à condition que vous lanciez effectivement ces finitions. Les équipes qui négligent la qualité et n’y reviennent jamais se retrouvent avec des fonctionnalités incomplètes de manière permanente.

Opérations

Une fonctionnalité qui relève à la fois de l’expérience utilisateur et des aspects opérationnels (journalisation, surveillance, alertes) se divise selon cette distinction. Déployez d’abord la partie destinée aux utilisateurs ; la partie opérationnelle est une étape ultérieure qui se déroule souvent plus rapidement, car la fonctionnalité est déjà en production et les lacunes sont visibles.

Qu’est-ce qui n’est pas une véritable scission ?

« Le front-end ce sprint, le back-end le suivant » n’est pas une division — c’est un report de la livraison, car aucune des deux parties ne peut être livrée seule. « Développez-le, puis rédigez les tests » relève du même principe : un code non testé est un risque, pas une partie distincte. Si une tâche n’a de valeur qu’une fois que sa partie correspondante est livrée, vous n’avez pas divisé l’histoire. Vous l’avez simplement planifiée.

Lorsqu’un article ne peut pas être divisé : effectuez un « spike »

Parfois, l’inconnue réside dans l’ampleur même du projet : personne ne s’est encore lancé dans une telle démarche, l’API du fournisseur ne permet pas de répondre à la question cruciale de la capacité de charge, ou le travail dépend d’une mesure dont personne ne dispose encore (valeur p99 actuelle, volume d’appels actuel, structure actuelle des données). C’est là que vous lancez un « spike » : une étude limitée dans le temps dont le résultat est une connaissance — un document, un prototype, une recommandation, une mesure — et non du code produit prêt à être déployé. Vous en ressortirez ainsi en mesure d’estimer honnêtement l’ampleur réelle du projet.

Les « spikes » sont souvent utilisés à tort selon le principe « commençons et voyons ce qui se passe ». Ce n’est pas un « spike » : il s’agit d’une story non estimée comportant des étapes supplémentaires. Deux signes indiquant que vous n’utilisez pas le bon outil : soit aucune question spécifique n’est abordée, soit le livrable est « la fonctionnalité est développée ». Le premier signifie que l’équipe n’est en réalité pas dans le doute ; le second signifie qu’il s’agit d’une story.

Si une seule tranche ne suffit toujours pas, cela signifie que le projet n’est pas encore prêt — il s’agit d’un projet à part entière. Définissez-le comme tel, communiquez le calendrier et cessez de prétendre qu’un sprint suffira.

Foire aux questions

Comment divisez-vous une user story ?

Divisez-le verticalement — en fonction des résultats pour l’utilisateur, de sorte que chaque tranche touche toutes les couches et aboutisse à un produit que l’utilisateur peut utiliser, même si celui-ci ne traite qu’un seul cas. SPIDR propose cinq lignes de découpe fiables : « spike », « path », « interface », « data » et « rules ». Choisissez celle qui produit une tranche que vous seriez réellement prêt à mettre en production.

Que faites-vous lorsqu’une user story est trop volumineuse pour un sprint ?

Divisez-la avant le début du sprint, de manière délibérée. Une story qui ne tient pas dans le sprint est reportée de manière peu satisfaisante — ce qui reste correspond généralement à la partie la plus difficile — ou livrée sous forme de sous-ensemble à moitié terminé. Ces deux options sont moins satisfaisantes qu’une division verticale délibérée en tranches pouvant chacune être livrées séparément.

Dans quels cas vaut-il mieux diviser une story plutôt que de l’estimer ?

Lorsque l’équipe ne parvient pas à l’intégrer dans un sprint, lorsque les notes sont très disparates (un 3 à côté d’un 13), lorsque la réponse « ça dépend » revient plus de deux fois à des questions de précision, ou lorsque l’histoire concerne plusieurs équipes. Un écart important ne traduit pas un désaccord sur les chiffres : il s’agit de deux stories qui se font passer pour une seule.

Qu’est-ce qu’un « spike » dans la méthode agile ?

Un « spike » est une étude menée dans un délai défini, lancée lorsque l’équipe ne parvient pas à évaluer l’ampleur d’une story sans en savoir davantage. Le résultat est une connaissance — un document, un prototype, une mesure — et non du code produit livrable. Deux éléments permettent de distinguer un « spike » d’un travail sans durée définie : un délai et un livrable.

Quelles sont les méthodes courantes pour diviser une user story ?

Les étapes du flux de travail, les variantes des règles métier, le scénario idéal puis le scénario défavorable, la qualité différée et les enjeux opérationnels — sans oublier les cinq critères SPIDR. Le critère d’évaluation est le même pour tous ces éléments : l’utilisateur y gagnerait-il si cette partie du projet était livrée et rien d’autre ?

Lectures complémentaires

• L’estimation agile : le guide complet — la plateforme de référence pour tout ce qui concerne ce sujet.
• Fractionnement de l’article SPIDR — les cinq lignes de coupure fiables, en détail.
• Découpage horizontal ou vertical — le principe qui sous-tend tout bon découpage.
• Définition de « prêt » — l’étape qu’un « split story » doit franchir avant de réintégrer le sprint.
• Affinement du backlog — la phase au cours de laquelle le fractionnement a effectivement lieu.