Avant de lire cette page, nous vous invitons à lire la page sur l’écriture de User Story

L’agilité prône la production et la livraison des produits par petits morceaux. L’objectif est d’augmenter la capacité à livrer des éléments de valeur rapidement.

Mais le découpage et la livraison régulière morceaux par morceaux a de nombreux avantages :

• Comme nous le disions, livrer régulièrement de la valeur
• Se concentrer en premier sur ce qui répond au besoin en séparant d’une grosse fonctionnalité le service qui répond au besoin fondamental des éléments secondaires
• L’alliance du découpage et de la priorisation permet d’ouvrir des portes et d’augmenter la capacité de décision. Le fait de pouvoir extraire d’un gros sujet le morceau le plus important permet de basculer vers un autre sujet fondamental plutôt que de continuer avec des services moins importants uniquement pour « aller au bout »
• Le projet se met en capacité de montrer le produit aux utilisateurs et récolter du feedback rapidement pour s’ajuster.
• Le risque que le produit ne convienne pas est inversement proportionnel au nombre de tests utilisateurs qui auront pu être fait tout au long du projet
• Le découpage permet de diminuer la complexité de traitement (par le fait de concevoir un ensemble fonctionnel trop grand) et limiter le risque de ne pas sortir une fonctionnalité
• Aussi, le découpage d’une fonctionnalité l’expose moins aux risques d’interruptions (problème matériel, indisponibilité des personnes affectées sur la fonctionnalité, concentration de la connaissance)
• Le chiffrage d’une petite fonctionnalité est plus simple que celui d’une grande fonctionnalité (lié à la complexité de conception)
• En traitants plusieurs petits sujets plutôt qu’un gros, nous augmentons notre capacité à intégrer à la volée des sujets potentiellement plus prioritaires sans interrompre la conception ou les développements

NB : Lorsque nous parlons ici de « conception », cela vaut pour de la conception technique mais aussi de la conception fonctionnelle. Penser à tous les tenants et aboutissants d’une grosse fonctionnalité apporte mécaniquement plus de complexité que pour un morceau fonctionnel de celle-ci

Une bonne User Story est une User Story potentiellement livrable et utilisable par des utilisateurs, à minima pour récolter leurs feedbacks.

Voici la liste des indices vous permettant de découper :

• L’intitulé de la User Story contient des conjonctions de coordination (et, ou, soit, voire) ou des virgules
  En tant qu’utilisateur
  Je veux accéder aux informations du véhicule et visualiser la description, le nom du propriétaire et la liste des personnes assurées dessus…
  Il y a en réalité 3 User Stories possibles : voir la description, le rattachement au propriétaire et le rattachement à d’autres assurés
• La User Story concerne différents utilisateurs qui peuvent ne pas avoir la même gestion de la fonctionnalité (les règles de gestion sont différentes, le besoin aussi)
  En tant qu’utilisateur
  Je veux gérer les nouveaux contrats…
  Il est nécessaire de creuser ce qu’il y a derrière le terme de « gérer » car si cela signifie créer et vérifier, cela peut concerner un ou une commerciale et un ou une gestionnaire.
• La User Story intègre des usages différents (afficher, filtrer, trier, créer, modifier, supprimer)
  En tant qu’utilisateur
  Je veux lister les nouveaux clients dans l’ordre de mon choix…
  Deux besoins ici, celui d’afficher et de trier selon des critères. Point de vigilance, ces usages, s’ils ne sont pas décrits dans l’intitulé de la User Story sont probablement cachés dans les critères d’acceptance.
• La User Story est composée d’étapes d’un processus (Je veux créer un utilisateur puis l’afficher dans une liste)
  En tant qu’utilisateur
  Je veux pouvoir valider ma commande pour ensuite être redirigé vers un suivi de commande
  D’abord gérer la validation de commande et ensuite monter le suivi de commande
• La User Story concerne plusieurs types de données
  En tant qu’utilisateur
  Je veux créer différents types de contrats
  Afin de répondre à des besoins spécifiques de mes clients
  Selon le contexte, il est possible que la gestion de données de différents types nécessite une spécificité et un comportement fonctionnel différent qui pourraient être traités de façon isolée.
• La User Story comporte plusieurs niveaux de complexité fonctionnelle
  En tant qu’utilisateur
  Je veux voir apparaître mes contrats au fur et à mesure que je tape le numéro
  Afin de trouver rapidement mes contrats
  Outre le fait que nous frôlons ici une demande de solution (demande d’un moteur de recherche et d’un comportement spécifique), le fait est que si la demande était malgré tout recevable, elle peut être découpée. Peut-être d’abord mettre en place un moteur de recherche simple où il faut taper tout ou partie du n° de contrat avant de voir apparaître les résultats. Il est probable que cela coûte moins cher et que le service soit rendu.

La réflexion sur le découpage peut se faire à différentes étapes de la User Story :

1. A l’écriture de l’intitulé « En tant que… je veux… afin de… » (tel que décrit ci-dessus)
2. A l’écriture des règles de gestion, des critères et tests d’acceptance
   En tant qu’utilisateur, je veux visualiser la liste de mes contrats afin de suivre leur avancementCritères d’acceptance :
   – Je dois pouvoir trier la liste par l’ID du client, son nom, son code postal
   – Je dois pouvoir filtrer le client par code postal et nom
   Nous voyons bien ici qu’apparaît une complexité supplémentaire à mesure que l’on creuse la solution avec l’équipe de réalisation.
   Il faut donc être très vigilant de bien garder en tête le besoin initial (afficher les contrats) car nous sommes toujours tentés d’ajouter des éléments qui peuvent générer : un nouveau besoin, un nouvel usage (le besoin d’afficher n’est pas le même que celui de trier ou filtrer), une information d’un type différent à gérer, une étape de processus (« Je veux valider mon contrat », – un email m’est envoyé après confirmation).
3. Au moment du chiffrage. Lors des échanges avec l’équipe de développement sur la User Story, le fait que l’équipe annonce un chiffrage très important est un bon signe pour vous inviter à la découper.
   Gardez en tête que le but n’est pas que la User Story soit petite. Le risque avec cet objectif est de faire un découpage technique (faisons d’abord la base de donnée puis l’interface…) créant ainsi des User Story qui ne pourront être testées et seront chaînées (et donc plus INVEST).
   Néanmoins cela vous invitera, avec l’équipe, à étudier les pistes de découpage que vous n’aviez peut être pas estimé nécessaire.

Tout au long de la construction du produit, un backlog doit être maintenu avec les différents éléments nécessaires à la construction du produit. Notamment des User Stories.

Le risque est d’essayer d’avoir dans le backlog, toutes les User Stories du produit et ainsi de générer une liste de plusieurs centaines d’items qu’il deviendra impossible à gérer avec le temps dans un mode de fonctionnement agile, c’est-à-dire en mouvement. Il est donc fondamental de maintenir un backlog réduit (avec moins de 40 éléments) pour rester dans la simplicité et en faciliter son usage,

Cela permettra d’intégrer, de prioriser, déprioriser plus facilement les éléments.

Comment dès lors, combiner un nombre faible d’éléments dans le backlog tout en gardant trace des différents sujets qui constitueront le produit ?

En découpant progressivement les User Stories.

Il est inutile de découper finement les User Stories très en avance car il est possible que le sujet se réajuste voir qu’il disparaisse. Il est recommandé de dégrossir un sujet lorsque le niveau d’information et de certitude quant à son développement se précisera.

Au-delà de 4 mois d’avance, maintenez les User Stories au niveau « Thème », c’est-à-dire grand sujet.

Exemple : « Gérer les contacts », « Envoyer des communications », « Accéder à une aide », « Suivre les ventes »

Entre 2 et 6 mois, piochez dans vos thèmes les morceaux prioritaires. Ces morceaux encore trop gros pour être développés deviendront des Features ou des Epics (dont la définition exacte est : une User Story qui peut être encore découpée).
Cette étiquette permet de signifier que vous avez commencé à affiner car le sujet se clarifie et semble de plus en plus incontournable.

A environ 2 mois avant son développement potentiel, piochez dans vos Features/Epics les morceaux prioritaires pour en faire des User Stories selon les critères proposés plus haut dans cet article.​​​​​​​

Le découpage est une des pratiques les plus difficiles et contre-intuitives de l’agilité.
Identifier les critères de découpage, basculer d’un sujet à l’autre en ayant toujours l’impression de ne pas être allé au bout sont des sentiments vécus par les Product Owners comme les équipes.

En réalité elles le sont lorsque le découpage n’est vu que comme la somme des morceaux d’une fonctionnalité qu’il faudra développer. Or l’idée de découpage est justement de se mettre en capacité de ne pas aller au bout d’une fonctionnalité qui avait été imaginée et qui, finalement, allait trop loin, c’est s’assurer que tout le monde se focalise sur ce qui est le plus important le plus tôt possible plutôt que d’aller au bout pour aller au bout.
​​​​​

Image de couverture : Photo de Kelly Sikkema sur Unsplash