Les user stories constituent le cœur du développement agile. Elles constituent l’apport principal de l’équipe de mêlée. Ils prennent les histoires d’utilisateur et crée des incréments de produit basés sur l’achèvement de ces histoires. Malheureusement, obtenir de bonnes user stories n’est pas si facile.
Vous pouvez connaître plus d’infos sur les user stories ici :
Les Product Owners doivent apprendre à créer des user stories qui répondent aux besoins de l’équipe. Afin de créer de bonnes user stories, commencez par vous souvenir d’INVESTIR dans de bonnes user stories. INVEST est un acronyme qui englobe les concepts suivants qui constituent une bonne user story :
Indépendante : Un élément du backlog de produit (PBI) doit être autonome.
Négociable : Doit laisser un espace de discussion.
Valable : Doit apporter de la valeur aux parties prenantes.
Estimable : Vous devez toujours être en mesure d’estimer la taille d’un PBI.
Petit : Vous devez ainsi être en mesure de le planifier, de l’affecter à des tâches et de le classer par ordre de priorité.
Testable : Le développement doit pouvoir être testé.
Les histoires doivent être aussi indépendantes que possible et vous devez pouvoir travailler sur elles dans n’importe quel ordre. Cela permet une véritable priorisation de chacune des histoires. Lorsque des dépendances entrent en jeu, il peut être impossible de mettre en œuvre une histoire précieuse sans mettre en œuvre d’autres histoires beaucoup moins précieuses.
Négociable
Une bonne histoire est négociable et non un contrat. Une bonne histoire est une invitation à une conversation. Une bonne histoire capture l’essence de ce qui est souhaité. Le résultat réel doit être le fruit d’une négociation collaborative entre le Product Owner et l’équipe de développement. L’objectif est de répondre aux besoins des clients.
Valeur
Les histoires d’utilisateurs doivent être classées par ordre de priorité dans le backlog en fonction de leur valeur commerciale. Arriver avec des éléments du backlog de produit qui sont vraiment amusants à coder mais qui n’apportent aucune valeur aux parties prenantes, viole l’un des principes agiles, qui est de livrer continuellement des logiciels de valeur
Estimable
Les développeurs doivent être capables d’estimer une histoire. Elle doit être écrite de manière à ce que les développeurs puissent la comprendre et avoir une idée de la manière de la mettre en œuvre. Les facteurs clés pour l’estimation sont la connaissance du domaine et la connaissance technique.
Petite
Les bonnes stories ont tendance à être petites, mais à quel point doivent-elles l’être ? La réponse dépend de l’équipe et de la méthodologie utilisée. Beaucoup de Product Owners suggèrent des itérations de deux semaines, qui permettent des user stories de trois ou quatre jours moyens de travail. Cela comprend tout le travail pour amener la story à un état « fait ».
Testable
Les stories doivent être testables afin d’aider à déterminer leur complétude. Une story devrait avoir un critère d’acceptation. Le critère d’acceptation devrait être objectif. Évitez d’utiliser des critères comme, facile à utiliser, rapide ou sans bogue. Try to write criteria that can be measured and tested.
Via: