Menu
Un projet en environnement agile s’articule autour d’acteurs spécifiques. Comme dans tout projet, les caractéristiques et les compétences de ces acteurs feront vivre ou, au contraire, condamneront un projet avant même sa mise en production. Alors, quels sont les critères indispensables à chaque rôle ?
En tant que chargé du produit, et donc du projet, le Product Owner doit :
Si les acteurs sont indispensables à une pièce de théâtre, le scénario est tout aussi important, et c’est là l’importance de bien écrire ses User Stories.
Une User Story bien composée mettra l’emphase sur la valeur ajoutée d’une fonctionnalité du produit. Elle doit donc être précise, sans être trop spécifique, pour parler à un public assez large. Elle doit répondre à un véritable besoin de l’utilisateur, sans pour autant être trop générique.
Les User Stories permettent de garder une dynamique très humaine dans l’approche des tâches : on peut facilement comprendre où vont les efforts de l’équipe. Elles favorisent également la collaboration et les solutions créatives, à la manière d’un brainstorming permanent.
Pour rédiger une bonne User story, voici un modèle très répandu :
En tant que [individu], je veux faire [quelque chose] pour obtenir [un résultat].
L’individu peut appartenir à différents publics ciblés par le produit développé. Cela peut être par exemple “novice en informatique” ou “développeur web”, du moment que cela vise un groupe de personnes qui utilisera une fonctionnalité.
Le quelque chose, quant à lui, recoupe l’intention de l’individu. Attention, ce n’est pas la méthode utilisée, mais la volonté de l’utilisateur. Il est important de distinguer entre l’idée de la personne et la fonctionnalité, peut-être encore à développer, qui en découle.
Enfin, le résultat est le reflet d’un problème à résoudre. C’est prendre conscience de ce problème qui amène généralement l’utilisateur à avoir recours au produit.
Les User Stories ne naissent pas égales : certaines sont prioritaires et sont généralement au centre de l’identité du produit. Ce sont celles-ci qu’il faudra développer en premier, avant de passer à des scénarios plus secondaires mais qui viendront consolider les fonctionnalités du produit.
Comment savoir par où commencer ?
Pour cela, il faut se référer au Backlog Product, élaboré par un Scrum Master vigilant. Un bon Backlog Product comporte :
En plus de cela, le Backlog Product évolue lors des sprints, à mesure que de nouveaux éléments nécessaires à l’élaboration du projet se dévoilent. C’est généralement lors de la réunion finale de sprint, lors du Sprint Meeting Review, qu’on ajoute et qu’on restructure le plus les tâches présentes dans le Backlog. Cette tâche d’entretien est nécessaire afin de pouvoir réviser les priorités de l’équipe et de repartir de plus belle sur un nouveau sprint.
