Une story qui ne tient pas dans un sprint doit être découpée en stories plus petites, chacune apportant encore de la valeur. Découper au hasard produit des morceaux inutilisables ; il existe des axes de découpe éprouvés.

Par étapes du parcours utilisateur

« Passer une commande » se découpe en : choisir un article, valider le panier, payer, recevoir la confirmation. Chaque étape est une story livrable.

Par variantes de règle

« Calculer les points » se découpe en : cas standard d'abord, puis promotions, puis parrainage. On livre le cas le plus fréquent, on ajoute les cas particuliers ensuite.

Par type d'utilisateur

« Voir ses points » pour une cliente, puis pour un membre de l'équipe en interne, puis pour un administrateur.

Par effort / valeur (le squelette d'abord)

Une version minimale qui marche (le solde s'affiche, texte brut), puis les améliorations (mise en forme, animation, historique).

Ce qu'il ne faut pas faire

Découper par couche technique : « la base de données », puis « le back-end », puis « l'écran ». Chaque morceau n'apporte aucune valeur seul, et on ne sait pas si l'ensemble fonctionne avant la fin.

Le test

Après découpe, chaque story doit rester INVEST : indépendante, avec de la valeur, testable. Si un morceau n'a de sens qu'avec un autre, la découpe est mauvaise.

Exemple concret : la story « gérer les points » de l'application de fidélité est découpée par variantes de règle : d'abord « gagner des points sur un achat simple », livrée au sprint 1 ; « points bonus en promotion » au sprint 2 ; « points de parrainage » au sprint 3.

À vous de jouer : prenez une fonctionnalité large et découpez-la en 3 stories selon l'un des axes vus.