Des User Stories ... de qualité

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.

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 8x13 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", des stories qui ne sont pas envisagés sur les tous prochains sprints et qui seront splittées en User Stories le moment venu.
  

• 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!