Souvent dans une équipe, on se concentre sur l’effet immédiat d’une fonctionnalité ou d’une tâche : le fameux “afin de…” d’une User Story.
Note : Si vous n’êtes pas sûr de ce qu’est une User Story, vous pouvez lire mon article sur le sujet : Scrum tips: Différences entre épiques, histoires, thèmes et fonctionnalités.
Cet élément de la User Story, le “afin de…” doit exprimer le gain que l’utilisateur va ressortir de la fonctionnalité, et non pas une suite séquentielle d’évènements.
Par exemple, dans cet exemple de User Story :
En tant qu’utilisateur Facebook, je veux être averti lorsque j’ai des articles dans mon panier afin de soit valider mon panier, soit le vider
Dans cette User Story, la partie afin de ne précise pas la valeur que l’utilisateur ressort de la fonctionnalité. On expose ici un comportement induit par l’US, au lieu d’un bénéfice.
« séquentiellement je fais ça, pour pouvoir faire ça ».
Une meilleure version de cette User Story serait par exemple :
En tant qu’utilisateur Facebook, je veux être averti lorsque j’ai des articles dans mon panier, afin de ne pas perdre une commande importante que j’aurais oubliée.
Dans cette version, l’US exprime au reste de l’équipe l’objectif de l’utilisateur et il est alors plus simple d’en déterminer l’impact attendu, par exemple :
- +10% de commande validée parmi les commandes non-terminée depuis 3h.
L’écriture des US est une des compétences de Product Owner les plus difficiles à maîtriser, ça demande de l’expérience et de se remettre en question et de prendre le rôle au sérieux.
L’impact, c’est une constituante essentielle d’une fonctionnalité comme nous en parlions dans cet épisode de Scrum Life : Product Owner – L’impact du produit – Scrum Life #82.
Vous en pensez quoi ?
Photo by Green Chameleon on Unsplash