Du bon usage des User Story et Epic

Définition d’une User Story

Les spécifications sont souvent une cause majeure de l’échec d’un projet. De mauvaises spécifications peuvent entraîner un manque de vision sur le produit attendu, des fonctionnalités redondantes/contradictoires.

Le but de l’utilisation des « user stories » est de permettre de répondre plus rapidement et avec moins de coût au changement rapide des exigences du monde réel.

En méthode agile, la US est écrite pour partager la vision développeur/testeur/projet à travers des revues fréquentes et non formelles en même temps que celles-ci sont rédigées/modifiées.
On retrouve ce partage également dans les cycles en V au travers de la notion des revues d’exigences/spéc très formelle après que celle-ci soit rédigée (moins d’A/R mais processus très figé — pas de modification en direct).
Les « user stories » décrivent les fonctionnalités qui seront utiles. Les « user stories » sont composées de trois aspects (principe des 3C):

• Carte : Support décrivant la story
• Exigence (description)
• Priorité
• Temps de dev/test
• Critère d’acceptance
• Conversation : Échanges sur la « user story » qui servira à étoffer les détails (Testeur/PO/Devs). Cette phase commence pendant la phase de planification de la release et continuera quand la User Story sera planifiée (mind-mapping/brainstorming)
• Confirmation: Les tests qui véhiculent et documentent les détails et seront utilisés pour déterminer quand une « user story » est terminée. Ces tests fonctionnelles/non fonctionnelles devront être montrés et suivi à travers le temps afin de satisfaire la US et être considérée comme « Done »
  [Mike Cohn : User Stories appliquée. 2009] [REQB® Certified Professional for Requirements Engineering Niveau Fondation]

Méthode Invest

Quelles sont les caractéristiques d’une bonne story ? L’acronyme INVEST est un bon moyen de réponse.

• I — Independent (Indépendante des autres)
• N — Negotiable (Négociable initialement, plutôt qu’un engagement ferme)
• V — Valuable (Ayant de la Valeur en soit)
• E — Estimable (Evaluée en termes de complexité)
• S — Small (Suffisamment petite)
• T — Testable (Testable en principe, ce qu’on vérifie en écrivant un test)

Plus en détail

Independante
Une story se doit d’être indépendante. De cette façon il doit être possible de planifier n’importe quelle story et de l’implémenter dans le système dans l’ordre que l’on veut. Cette indépendance permet également lors de test de retirer des storys défaillantes de la release.

Négociable… et Négociée
Une bonne US doit dans un premier temps ne pas contenir d’élément technique étouffant la story, on se limitera à l’essentiel lors de la définition de la release (macro chiffrage). Ces éléments seront ajoutés par la suite lors des échanges entre les testeurs/développeurs et le rédacteur de la story.

Avec de la Valeur
Une US se doit d’avoir une valeur pour l’utilisateur final. Exemple : la refactorisation de code n’est pas quelque chose de pertinent d’un point de vue utilisateur. Lors d’évolution majeur, il arrive souvent que l’équipe développement décide d’entièrement prendre de l’avance sur des tâches techniques (sur l’ensemble du projet) au lieu de se concentrer que sur la partie voulue par l’utilisateur. Il vaut mieux ne livrer qu’une partie du projet de façon régulière que de prendre du retard sur des tâches techniques n’affectant par l’utilisateur final (projet vertical)

Estimable
Une bonne US doit être évalué (complexité). Afin de répondre à ce point, les critères d’acceptations devront être précis et compris par l’ensemble des équipes. De plus la US ne devra pas être trop grosse (1 US ne doit définir à elle seul un projet)

Taille S (Small)
Une bonne US ne doit pas dépassé quelques jours-hommes. Sinon il faut la splitter en plus plusieurs story et la story initial devenant une EPIC.

Testable
Une bonne US est testable. Il faut que la description et critères d’acceptante de celle-ci soit suffisamment pertinent pour ne pas laisser d’ambiguïté lors des tests. C’est une des critères les plus importants d’une story.

Définition d’une EPIC

Une Epic correspond à une macro fonctionnalité du système à développer. Elle englobe de ce fait un ensemble de User Stories qui seront rattachées à l’EPIC.

On retrouve souvent l’EPIC dès le début d’un projet; à ce stade la fonctionnalité n’est pas du tout détaillée ni priorisée. C’est au fur et à mesure que la fonctionnalité sera spécifiée que l’Epic va être complétée par l’ajout/suppression de User Story. De par le découpage en US, le développement d’une EPIC se fera en plusieurs versions (ou sprints).