Epic et User Stories

Epic et user story

Epic agile

Une epic est une grosse user story non encore affinée qui n’est pas envisagée pour les prochains sprints. Elle sera découpée en User Stories le moment venu.

User story agile

Une User story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur. Les User Stories émergent au cours d’ateliers de travail menés avec le Métier, le Client ou les Utilisateurs.

Quelques Exemples :
« En tant que recruteur, je peux déposer des offres d’emploi »; « En tant qu’utilisateur, je peux réserver une chambre d’hôtel »;  » En tant utilisateur, je peux annuler une réservation »; « En tant que jeune diplômé, je peux créer un CV »; « En tant que jeune diplômé je peux supprimer un CV »; « En tant que jeune diplômé je peux modifier un CV »…

Bref, je vous en ai déjà parlé des User Stories au travers de leurs différences et similitudes avec les « Use Cases » (cas d’utilisation), et les considère dans pas mal de contextes beaucoup plus appropriées.

Critères de qualité des user stories

Dans des contextes agiles, elles sont pour moi indispensables, mais ne sont pas forcément faciles à appréhender par les équipes « Métier », chargées souvent de les rédiger.
Comment rédiger de bonnes User stories ? voilà une question qui revient souvent sur les projets où je suis coach …

Ma réponse se fait d’abord en deux temps: 3C et critères INVEST !

Les 3C:

  • Card (l’histoire est courte, une ou deux phrases et peut être écrite sur une carte 8×13 cm, c’est mieux)
  • Conversation (les détails de l’histoire sont discutés par les équipes avec le métier, les ergonomes …)
  • Confirmation (l’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte) : c’est un élément majeur

Critères INVEST:

  • I – Independent. Une bonne User Story est indépendante (des autres User Stories, bon autant que possible) notamment pour faciliter son traitement; car le choix de l’inclure dans tel ou tel sprint (= itération) est avant tout fondé sur la priorité qu’on lui donne (rappelez vous ce billet …)
  • N – Negotiable. Elle est négociée, discutée (c’est le second C, Conversation) dés les réunions d’estimation (planning poker) et de planification du Sprint mais aussi tout au long de ce dernier.
  • V – Valuable. Elle est source de valeur pour le Client final ou l‘utilisateur (c’est aussi ça le Lean Thinking !).
  • E – Estimable. Elle est estimée par les équipes de développement; une estimation relative c’est à dire les unes par rapport aux autres, en story points.
  • S – Size Appropriately. Le plus souvent petite car susceptible d’être traitée (livrée et testée) par l’équipe sur une seule itération de 2/ 3 semaines. Le niveau de granularité est une question fréquente. L’affaire est très contextuelle mais je conseille le plus souvent une petite taille qui va faciliter là aussi son estimation, sa décomposition en tâches puis son traitement (codage et test) sur un maximum de quelques jours. Il existe des User Stories plus « grosses », nommées « epics » : elles seront découpées pour avoir la bonne taille et être embarquées dans un sprint.
  • T – Testable. Une User Story « de qualité » est avant tout testable, déjà dans sa forme et surtout dans le sens où les critères d’acceptation sont envisagés d’entrée (le troisième C, Confirmation). Si elle n’est pas testable ou vérifiable ce n’est pas une User Story. La définition de ces critères d’acceptation est un premier pas vers la qualité qui aidera à la fois la décomposition en tâches et l’activité de développement!

2 Comments

  1. Toujours bon à rappeler, merci!
    Maintenant, au delà des classiques 3C et INVEST qui doivent à mon sens être systématiquement respectés, le conseil qui dans mon expérience s’avère le plus efficace pour obtenir in fine de bonnes user stories est de respecter un format prédéfini tel que celui mentionné ci-dessus: "En tant que… , je veux… afin de …", qui s’avère notamment particulièrement efficace pour faciliter l’application d’un autre principe important, à savoir que c’est au client (au sens large) qu’il incombe de rédiger les User Stories (et les tests d’acceptation qui vont avec)!

  2. salut d’abord merci pour les informations fournis.
    pouvez vous me dire comment rendre une user story testable??
    Merci

Les commentaires sont fermés.