Quelques petites notes sur les user-story

La User Story doit être :

INVEST

La User Story doit comporter :

  • le besoin “la formule”
  • les règles métier
  • les test d’acceptance
  • la taille / la complexité
  • la priorité

3C

  • Carte : l’histoire tient sur une carte.
  • Conversation : elle est principalement discuter à l’oral
  • Confirmation : on précise comment on va la confirmer, la valider.

Formule

Une formule efficace pour exprimer le besoin :

  • En tant que qui ?…
  • Je veux quoi ? …
  • De façon à pourquoi ? …

Et une pour proposer un comportement qui valide le besoin :

  • Etant donné une situation…
  • Quand se produit …
  • Alors j’obtiens …

INVEST

I indépendante
N négociable
V avec de la valeur
E que l’on peut estimer
S suffisamment petite
T testable

ce qui veut dire :

I – Une US peut être traité/embarqué qu’une fois que ses dépendances avec d’autre partie (autres équipes technique par exemple) sont OK. Elle doit être également indépendante des autres US.

N – une User Story doit être un support de discussion en vue d’une amélioration du besoin initial

V –  la réalisation d’une User Story doit rendre un service à l’utilisateur. En un mot, une User Story n’a de sens que si elle apporte une valeur métier;

E – une User Story doit être bien définie pour être facilement chiffrable

S –  Une US doit être assez petite pour être traité lors d’une seule itération.
Si celle-ci est trop grosse, c’est une “epic story”. Elle doit donc retourner dans le backlog pour être divisé en story.

T – On peut mettre en place un protocole de test qui validera la storie comme réalisé // une User Story  doit être accompagnée de ces critères d’acceptabilité pour faciliter sa validation.

Test d’acceptance :

  • Etant donnée que : l’état du logiciel avant l’exécution de la user story
  • Quand : un événement qui déclenche un processus
  • Alors : l’état du logiciel après l’exécution

Le test d’acceptance doit-être SMART :

  • Specific  : compréhensible, facile à reproduire
  • Measurable : quantifiable et observable
  • Achievable : possible à réaliser (sans complexité excessive)
  • Relevant :  approprié à la user story en question
  • Time bound  : avec un moment d’application circonscrit dans le temps

Partager