agile user stories specifications - 07 Dec 2015

Spécifions les user stories

Sébastien SOLERE
Écrit par Sébastien SOLERE

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

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.