Fractionnement de l'histoire – affinement jusqu'à une granularité optimale
Une histoire apparemment petite peut s’avérer bien plus importante que prévu. Ce n'est que par le raffinement ou le fractionnement de l'histoire que vous pourrez découvrir cela. Le fractionnement de l'histoire peut être effectué tôt ou juste avant le sprint précédent. Nous vous recommandons de le faire le plus tôt possible pour éviter les surprises tardives.
Nous considérons le « découpage d’histoire » et le « raffinement d’histoire » comme des activités très similaires. Il s’agit d’optimiser la granularité de la user story écrite.
Que sont les user stories
Pour les équipes qui peuvent colocaliser, la user story peut être simplement un rappel d'une conversation. Dans la plupart des cas, nous nous appuyons sur la user story comme exigence fonctionnelle écrite. Pour être efficace dans la fourniture communication claire les user stories doivent être soigneusement rédigées pour minimiser les malentendus. Mais nous devons d’abord comprendre comment les user stories s’inscrivent dans le contexte plus large (hiérarchie) de communication de ce qui doit être fait pour apporter de la valeur aux utilisateurs :
Le contexte des user stories
Une user story complète
Après avoir établi ce contexte, nous pouvons maintenant voir où s’intègrent les user stories. Le contexte au sein de la hiérarchie permet de comprendre ce qui est nécessaire dans une user story, pour qu’elle soit bien formée et de bonne qualité. Une user story complète doit :
- spécifier un utilisateur ou personnage doit être précisé.
- décrire le fonctionnalité de haut niveau à effectuer dans le cadre d'une seule action fonctionnelle discrète de la part de l'utilisateur.
- inclure toutes les étapes fonctionnelles nécessaire pour répondre aux besoins des utilisateurs.
Quand faire le fractionnement de l'histoire
Idéalement le plus tôt possible dans le cycle de vie du logiciel. Ce n’est pas aussi onéreux que beaucoup le prétendent et constitue rarement une activité inutile. Consultez notre article de blog sur attributs de qualité de user story recommandés
Techniques de fractionnement d'histoire
Réfléchissez d'abord à qui est l'utilisateur et à quels types de données doivent-ils gérer pour répondre à une exigence spécifique qui laisse le système dans un état stable à la fin.
Utilisateur – Orienté
Cette histoire décrit-elle les fonctionnalités d'un personnage ou de groupes de personnages ?
Mesurable (étapes fonctionnelles claires)
Afin d'être mesurable ou important, nous devons connaître la fonctionnalité en termes de groupes de données traités. par exemple
en tant qu'utilisateur enregistré, je peux mettre à jour mon profil.
Pour les mesurables, nous recommandons la norme de dimensionnement fonctionnel COSMIC, qui exige que les objets d'intérêt soient identifiés.
Complet
Avons-nous mentionné tous les groupes de données nécessaires pour cette histoire ? Si nous devons rechercher des données ailleurs, elles doivent également être incluses. De nombreuses user stories nécessitent diverses recherches de données avant qu’un type d’objet ne soit créé ou mis à jour.
Règles commerciales
Les règles métier sont généralement des contraintes basées sur le contexte ou des données référencées. Assurez-vous d'inclure tous les types de données référencés dans votre user story fonctionnelle. Parfois, les règles métier obligent à diviser une histoire en deux histoires similaires. Parfois, le contexte peut être présenté en combinant le nom d'utilisateur avec un statut particulier, par exemple connecté._user_with_cart_items
Concis
Parfois, nous sur-spécifions une user story avec tous les critères d'acceptation avant d'avoir les bonnes bases. Évitez de le faire trop tôt.
