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 sur le fractionnement déguisées. L’équipe n’est pas confrontée à un problème lié aux chiffres et à l’effort ; elle est confrontée à un problème lié à un trop grand nombre d’inconnues. Le fractionnement permet de réduire 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 qui est reporté correspond généralement à ce qui était le plus difficile) ; 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 situations sont pires que de diviser délibérément le travail avant le début du sprint.

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

Lorsqu’une équipe de taille similaire travaille avec la méthode du « planning poker », un écart important constitue le signal le plus utile qu’elle puisse produire. Des cartes réparties entre 3 et 13 ne reflètent pas un désaccord sur les chiffres. Il s’agit de deux scénarios différents 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 arrière-plan :

• 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 allonge le ticket, sans pour autant affiner l’estimation. Le fractionnement, en revanche, 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 découpage doit être vertical, et non horizontal : une fine tranche qui soit réellement livrable en tant que telle. « 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 d’entrée. Consultez la section « Tranchage horizontal vs vertical » pour découvrir le principe dans son intégralité.

Des stratégies de fractionnement qui font leurs preuves

Le modèle SPIDR (spike, path, interface, data, rules) couvre la plupart des cas de fractionnement, et c’est par là qu’il faut commencer. Quelques autres modèles reviennent suffisamment souvent pour qu’il vaille la peine de les mentionner.

É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 de manière très nette selon les limites entre les é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 workflow 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), ce qui leur donne l’impression d’être granulaires. Elles sont effectivement granulaires. Mais ce sont aussi des tranches horizontales sur lesquelles s’appuie un vocabulaire de 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 toute la pile, car c’est le cas des véritables étapes en contact avec l’utilisateur.

Variantes des règles métier

Une feature comportant plusieurs règles ou rôles (utilisateur standard, administrateur, client API) est divisée par règle. Déployez d’abord la règle la plus courante ; les variantes suivront. Chaque variante constitue une véritable feature avec ses propres utilisateurs.

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

Ce concept est étroitement lié à l’approche Path de SPIDR. Commencez par mettre en œuvre le scénario optimal ; 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

Livrez la version préliminaire sans les améliorations (pas d’infobulles, pas d’animations, pas de modifications administratives), puis livrez les améliorations dans le cadre d’une story distincte. Cela fonctionne à condition que vous livriez effectivement ces améliorations. Les équipes qui négligent la qualité et ne reviennent jamais sur le sujet 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 ne constitue pas une véritable scission ?

« Le front-end ce sprint, le back-end le suivant » ne constitue pas une division ; il s’agit d’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 cette démarche, l’API du fournisseur ne répond pas à 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 à durée déterminée 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 en mesure d’estimer honnêtement l’ampleur réelle de la tâche.

Les « spikes » sont souvent utilisés à tort selon le principe « commençons et voyons ce que ça donne ». Ce n’est pas un « spike » ; c’est 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 ne trouve de réponse, 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 élément que l’utilisateur peut utiliser, même si cela ne concerne qu’un seul cas. SPIDR propose cinq lignes de découpe fiables : pointe, chemin, interface, données, règles. 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 rentre 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é développé. 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 peut 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 workflow, 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 en tirerait-il un avantage si cette partie était livrée et rien d’autre ?

Lectures complémentaires

• « L’estimation agile : le guide complet » est la référence incontournable sur le sujet.
• Le système de découpage de récits SPIDR aborde en détail les cinq lignes de découpage fiables.
• Le découpage horizontal par opposition au découpage vertical est le principe qui sous-tend toute bonne répartition.
• La définition du terme « prêt » correspond à l’étape qu’un « split story » doit franchir avant de réintégrer le sprint.
• L’affinement du backlog est la phase au cours de laquelle le fractionnement a lieu.