Définition d'une User Story

Agilité en entreprise

Qu’est-ce que c’est ? 

En quelques mots, c’est une description d’un besoin qui doit être rajouté à l’application. Cette US sera challengée par l’équipe durant un backlog refinement et ensuite estimée. Elle doit « tenir » dans un Sprint pour pouvoir être planifiée. Les User Stories sont écrites par les Product Owners

 

Une US doit être obligatoirement « INVEST » : 

Independant = Ne doit pas avoir de dépendance avec une autre US pour sa réalisation 

Negociable = Doit être négociable par l’équipe  

Valuable = Doit apporter de la valeur au produit 

Estimatable = Doit être mesurable par l’équipe (En Story Points et en Business Value)

Small = Il est plus facile d’estimer et de planifier des petites US que des grosses 

Testable = Doit être facilement testable pour vérifier qu’elle est bien réalisée 

 

Comment écrire une bonne US ?  

Le moule « As – Given -When – Then” permet de vérifier que nous avons l’ensemble du besoin : 

« As » …  Profil(s) / Persona(s) 

« Given » …  Contexte 

« When » … Action réalisée 

« Then » …  Résultat obtenu 

 

Best Practices : 

  • Doit être court 

  • Doit être simple 

  • Ecrite de la perspective d’un utilisateur 

  • Rendre la valeur/le bénéfice de la Story clair (Pourquoi on en a besoin ?) 

  • Décrire les fonctionnalités UNE par UNE au cas où la Story doit être découpée. 

  • Ecrire les Stories en équipe si possible 

  • Utiliser les critères d’acceptance (AC) pour démontrer le minimum acceptable 

 

Critères d’acceptance / Acceptance criterias (AC) : 

Ce sont les critères qui permettent de validés l’US lors du test. Ce sont des cas concrets qui permettent de vérifier que la logique métier / fonctionnel est bonne. Exemple : Si j’ai un article à 20€ et une TVA à 20% en cliquant sur le bouton « calculer la TVA » j’obtiens 4€ de TVA. 

Tags: 
Agilité