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

Une fonctionnalité dont vous ne pouvez pas estimer le coût est généralement une fonctionnalité que vous ne pouvez pas encore livrer. Comment déterminer quand il faut la diviser, quelles sont les lignes de découpe qui permettent d'obtenir des parties livrables, et celles qui ne font que donner l'illusion d'une livraison possible.

Diviser une user story consiste à découper une story trop volumineuse en plusieurs stories plus petites, chacune apportant 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 la décomposition des tâches 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. 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 peut pas être intégrée dans un sprint n’est pas un problème de taille, mais un problème de forme. Soyez attentifs aux signaux 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 une partie livrable et considère le travail comme terminé, tandis que le reste reste à moitié réalisé. Ces deux options sont pires que de diviser délibérément le travail avant le début du sprint.

One oversized story splitting into three thinner slices ? ? too big won't fit in a sprint ✓ slice 1 shippable ✓ slice 2 shippable ✓ slice 3 shippable each slice ships on its own
L’histoire qui ne tient pas en un tout se divise en trois parties qui se suffisent à elles-mêmes, et non en deux moitiés vides de sens.

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

Lorsqu’une équipe de taille variable travaille avec la méthode 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. Celui qui attribue un 3 perçoit une portée ; celui qui attribue un 13 en perçoit 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 ; 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 donne un ticket plus long, mais pas une estimation plus précise. 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 à la verticale, et non à l’horizontale

La division doit être verticale, et non horizontale : une fine tranche qui soit réellement livrable en soi. « Le backend d’abord, le 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. Voir découpage horizontal vs vertical pour le principe dans son intégralité.

Des stratégies de fractionnement qui font leurs preuves

SPIDR (spike, path, interface, data, rules) 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 de manière très nette selon les 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 » satisfait à ce critère : un utilisateur ayant défini ses préférences, mais n’ayant pas reçu de confirmation par e-mail, peut toujours utiliser la fonctionnalité. « Envoyer le formulaire » échoue : un utilisateur dont l’envoi n’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 division est fausse. C’est le piège dans lequel tombent les équipes d’ingénieurs : les étapes correspondent à la manière dont le code est décomposé (service d’authentification, API des préférences, composant du tableau de bord), ce qui leur donne une impression de granularité. Elles sont effectivement granulaires. Mais ce sont aussi des tranches horizontales surmontées d’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 de workflow traversent la pile, car c’est ce que font les 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 place le scénario optimal ; la gestion des erreurs, les tentatives de reprise et les cas limites viendront ensuite. L’utilisateur peut réussir même avant que les modes de défaillance ne soient entièrement gérés, à condition que vous acceptiez un comportement de défaillance moins optimal dans l’intervalle et que vous y reveniez effectivement 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 ce principe. Déployez d’abord la partie destinée aux utilisateurs ; la partie opérationnelle est une étape ultérieure qui s’effectue 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 la partie correspondante est livrée, vous n’avez pas divisé l’épisode. Vous l’avez simplement planifiée.

Lorsqu’un article ne peut pas être divisé : utilisez 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 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 à 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 la portée 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 » ; c’est une story non estimée comportant des étapes supplémentaires. Deux signes indiquant que vous utilisez le mauvais outil : soit aucune question spécifique n’est abordée, soit le résultat attendu 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 celui-ci ne traite 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 tient pas dans le sprint est soit reportée de manière peu satisfaisante (ce qui reste étant ce qui était le plus difficile), soit 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 éloignées les unes des autres (un 3 à côté d’un 13), lorsque la réponse « cela dépend » revient plus de deux fois lors 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éthodologie agile ?

Un « spike » est une étude dont la durée est clairement définie, mené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 prédéfinie : une limite de temps 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 optimal 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