Pour débuter dans une gestion de projet agile, il est intéressant de bien comprendre la user story. Ce terme offre un cadre à la définition des besoins de l’utilisateur que l’on cherchera in fine à prioriser. Je me permet ici une explication simple et rapide, pour des organisations fonctionnant en cascade. Afin d’éviter une approche souvent trop lourd et hyper normées.
Qu’est-ce que la user story ?
C’est une description d’un besoin ou d’une attente utilisateur. Ce besoin est placé dans un parcours pour l’usager aussi nommé cas d’usage. La user story est définit par le chef de produit aussi nommé Product Owner.
L’ensemble des user stories formeront des fonctionnalités qui seront listées dans un réservoir nommé product backlog. L’intérêt d’une user story est de définir le produit avec clarté, sans contrainte technique, et favorisant la participation de personnes non techniques.
Comment rédiger une user story ?
La formule magique très grandement utilisé est la suivante : En tant que … je souhaite … afin de … Cette formule permet de décrire en une phrase l’utilisateur, son action (quoi) et son objectif (pourquoi).
Face à la quantité de user story, il est également préférable de lui donner un numéro, un titre, un niveau de priorité et si possible une estimation grossière de la quantité de travail à produire. De plus, afin de vérifier que le besoin est atteint, il est souhaitable de décrire des critères d’acceptabilité. Ces critères suivent une seconde formule magique : Étant donnée que … lorsque … alors …
Exemple de user story
Et ensuite qui fait quoi ?
La production est assurée par une équipe de développeurs ayant un développeur expérimenté, polyvalent, compétent et souvent touche-à-tout aussi nommé lead developer ou lead dev. L’équipe peut être coaché par un Scrum Master appliquant la méthodologie Scrum. Celle que je cherche à décrire ici.
Un designer améliorera grandement la récupération des besoins utilisateur, la conception des parcours et le développement des interfaces. Il sera le bras droit du responsable produit qui fera l’interface avec les parties prenantes.
Rythme de travail
Maintenant, il n’y a plus qu’à définir les priorités ensemble. Je préconise de lister les user stories priorisées dans un Kanban afin de faciliter le suivi du projet. On nomme cette réunion le Sprint planning. Suite à cette réunion, nous saurons combien de user stories nous attendons pour la fin du premier cycle. Pour comprendre ce cycle, nommé sprint, je vous invite à écouter l’agiliste Florent Lothon (15 min). Un sprint peut durer, une, deux, trois semaines… A la fin du sprint, l’ensemble de l’équipe se réunira afin de présenter le produit aux différentes parties prenantes et de récolter un maximum de retours constructifs. Cette présentation sera une seconde cérémonie nommé la revue de sprint.
Enfin, pour offrir un cadre bienveillant, je vous conseille de lire le manifeste pour le développement agile de logiciels présentant les 4 valeurs et 12 principes de cette méthodologie. Et pour aller plus loin, voici une présentation synthétique.
