Spécifions les user stories

L'écriture d'user stories n'est pas aussi simple qu'elle peut le paraître. Avec un minimum de guide, on peut s'améliorer rapidement.

Ecrire des user stories est déjà bien compliqué ; si le product owner n’a pas un minimum de guide, ça devient impossible pour celui qui n’a pas l’habitude de le faire.

Spécifions les user stories

Chaque product owner devrait lire les livres de Gojko Adzic (http://books.gojko.net/). Ses livres peuvent être très utiles pour tout développement itératif et l'écriture de user stories.

5 principes basiques peuvent aider les product owners à rédiger leurs stories

  • une user story, c'est d'abord exposer un besoin utilisateur à travers l'écriture de sa justification : "afin de…, en tant que …, je veux"
  • une US est jetable, elle sert à introduire la discussion sur la fonctionnalité mais n'est pas la spécification fonctionnelle
  • les critères d’acceptation d'une US permettent d'en faire le tour pour estimer sa compléxité
  • les spécifications peuvent s’écrire sous forme de tests d’acceptation avec des exemples pour permettre à toute l'équipe de bien comprendre le besoin
  • à plusieurs, on va plus loin : un product owner peut être aidé dans sa tâche en profitant de l'intelligence collective de l'équipe

On part du principe qu’une user story ne peut démarrer tant que les critères d’acceptation et les éléments graphiques n’ont pas été discutés.

On peut alors établir un workflow de création des éléments pour une fonctionnalité :

  1. Ecrire la user story (ou les user stories) avec sa justification
  2. Ecrire les critères d'acceptation
  3. Poser les éléments graphiques si nécessaire
  4. Discuter et rediscuter du tout
  5. Etablir les tests d’acceptation à partir des critères en utilisant des exemples
  6. Définir les écrans (IHM) aussi précisément que nécessaire
  7. Préparer les textes
  8. Valider l’ensemble une fois développé
  9. Ecrire la spécification de la fonctionnalité reprenant les tests d’acceptation, les IHM et les textes sur ce qui a été réellement validé

A partir de ces éléments et en fonction de l’équipe, on peut avoir des organisations différentes où certaines tâches sont réalisées en amont du sprint (IHM, critères d’acceptation) ou sont prises dans le sprint et réalisées avant de démarrer le développement de la story.

Chez Elao, nous accompagnons nos clients pour les aider à améliorer leurs users stories. C’est simple : avec des bonnes user stories, on fait des meilleurs développements.