Comment bien rédiger ses User stories dans scrum ?

Une bonne rédaction des user stories dans la communication Scrum est essentielle. Comme le dirait Tyrion Lanister dans Game of Thrones : “Il n’y a rien de plus puissant au monde qu’un bon récit.”

User story ou récit de l’utilisateur en français, est un terme très utilisé dans les projets agiles comme Scrum ou kanban. Il s’agit d’une demande fonctionnelle d’un ou de plusieurs utilisateurs d’un produit qui cherchent notamment à ajouter de la valeur business au produit. Elle est rédigée par un/e Product Owner qui va l’affiner grâce aux ateliers de rédaction de US. Ces dernières seront insérées dans le backlog au fur et à mesure et seront mises en ordre par le/la PO en fonction de leurs valeurs.

Une user story doit avoir un titre, une description, une règle métiers et des tests d’acceptance.

1 – Le titre :

Il s’agit d’un élément très important qui nous permet ainsi de comprendre la demande. Il doit être exprimé avec un langage simple et facile à comprendre. Exemple : “Construire Stormbreaker”

2 – La description :  

Il existe plusieurs modèles de formulation pour faciliter la rédaction d’une US. La plus utilisée présente une vision utilisateur et elle est composée de 3 parties :

Le template des User Stories dans scrum sert à maintenir une bonne qualité de spécifications.

Pour bien remplir le tableau ci-dessus, il faut poser 3 questions : 

A- Qui a exprimé le besoin ? ou Qui bénéficiera de la demande ?

B-  Quel est le besoin ou la demande ?

C- Quelle est la valeur ajoutée ou le bénéfice si nous répondons à cette demande ? 

3 – Les règles métiers ou les règles de gestion des user stories dans scrum :

Les règles métiers sont des conditions qui doivent être exprimées avec des phrases courtes. Elles sont écrites avec un français simple afin d’éliminer toute confusion ou complexité de la part de l’équipe de développement. Elles leur permettent de comprendre le travail à faire.

 Exemple : 

J’établie la relation entre les pierres de l’infini et la destruction de l’univers :

Si Thanos récupère les 6 pierres de l’infini et claque des doigts alors la moitié de l’univers se détruira

Si le nombre de pierres possédé par Thanos est inférieur à 6, alors il ne pourra pas détruire la moitié de l’univers.

4 – Les tests d’acceptance : 

Ce sont des scénarii qui valident l’ensemble de la US 

Exemple : 

Scénario 1 

Etant donné que je suis sur Nidavellir 

Et que je suis Thor

Accompagné de Eilir et de Groot 

Alors Stormbreaker peut être construit.

Scénario 2

Etant donné que je suis sur Nidavellir 

Et que je suis Thor

Sans l’expertise de Eilir

Alors Stormbreaker ne peut pas être construit.

Les bonnes user stories réunissent 6 caractéristiques

(Copyright Agile Testing Alliance Global Gathering)

Indépendante : Chaque US doit être complète et indépendante des autres, ce qui permettra notamment de changer l’ordre du backlog facilement.     

Négociable : Une US reste un sujet de discussion et d’affinement jusqu’à son intégration dans un sprint. Les US d’un sprint backlog ne sont pas modifiables.

Valorisable : Une US sans valeur métier est obsolète.  

Estimable : Une US doit être claire et bien définie pour faciliter le chiffrage.  

Small : La réalisation d’une US ne doit pas dépasser un sprint sinon il faudra la découper.

Testable : Une US doit être facile à tester sans contrainte.

La rédaction d’une User story peut paraître simple pour beaucoup d’entre nous, mais ce n’est pas le cas. Certains besoins sont compliqués et pour les exprimer en quelques phrases simples et courtes, il faut beaucoup d’entraînement. Mais avec le temps ça devient plus facile !

Si vous souhaitez en savoir plus sur les bénéfices de la mise en place de la méthode Agile, découvrez aussi le témoignage de Jérémy Amourous, DSI de Colissimo. 

_____________________________________________________________________________

Tout simplement “Agile Fan” !

N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!

Nidhal