Les « User Stories » sont de plus en plus utilisées sur les projets Agiles, et c’est une très bonne chose.
Leur simplicité, leur orientation à la fois « But Utilisateur » et « Valeur Business », ainsi que le focus immédiat sur les critères d’acceptation les rendent en effet terriblement efficaces pour les projets de conception.
Une fois la règle des 3 C assimilée (Carte, Conversation et Confirmation) et les critères INVEST bien décrits, quand les équipes et le Product Owner commencent à découvrir les stories, ils me demandent souvent si le format « User Voice » doit être respecté …
Ce format c’est le fameux :
En tant que < Rôle d’utilisateur >,
Je peux < But >,
Si bien que < Justification >
Un format au sein duquel,
- Le rôle représente celui qui fait l’action et qui en bénéficie
- Le but représente l’action accomplie
- La valeur Business représente les bénéfices qui se dégagent de l’action
Alors, doit-on utiliser ce format ? Ma réponse est sans équivoque OUI !
- Le format « User Voice » donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer
- Il permet de se rapprocher d’une démarche expérience utilisateur, et notamment Personas. Le rôle c’est notre Persona, une vision concrète, réaliste et partagée de l’utilisateur final.
- Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace)
- Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
Mon conseil : Donnez un titre à la User Story (court et signifiant), et décrivez là ensuite au format « User Voice » !
Hello.
Serait il possible d’avoir quelques exemple pour illustrer notamment le « justification », svp ?
En vous remerciant,
Désolé pour le temps de réponse …
Voici un exemple de User Story au format User Voice:
« En tant qu’acheteur, je peux voir les commentaires des internautes sur un produit si bien que je peux décider si je l’achète ou pas «