Dans ce chapitre, vous allez apprendre à reconnaître et à évaluer des User Stories (ou récits utilisateur). En développement agile, ces User Stories sont des phrases simples rédigées dans le langage de tous les jours. Elles vont permettre à votre équipe de décrire précisément toutes les fonctionnalités du projet.
Les User Stories pour l'équipe agile
Dans la partie précédente, vous avez collecté les besoins utilisateurs du produit ou du service à développer. Leurs demandes étaient souvent exprimées de façon complexe et agglomérée. 😵
C'est la raison pour laquelle le recueil de vos entretiens individuels mélange souvent :
des usages personnalisés ;
des situations professionnelles ;
des procédures plus ou moins précises ;
des organisations idéales ;
des solutions pratiques.
Vous devez faire très attention à l’ambiguïté des informations transmises par les utilisateurs. La formulation à l'oral peut aussi amener des erreurs d'interprétation. Désormais, vous allez exprimer les besoins utilisateur le plus uniformément possible, afin de faciliter le travail de votre équipe.
Votre équipe rédige une User Story pour rendre le besoin utilisateur précis et compréhensible. Cette phrase doit seulement contenir 3 éléments descriptifs : Qui ❔ Quoi ❔ Pourquoi ❔
Le contexte → en tant que <utilisateur>.
La fonction → je veux <fonctionnalité>.
Le bénéfice → afin de (pour) <raison>.
En tant que joueur, je veux visualiser le plan du jeu d'évasion afin de m'orienter.
Les User Stories pour le coach agile
Toutes les User Stories pertinentes sont réunies dans le carnet du projet, ou product backlog, qui reste sous la responsabilité de votre client (ou de son représentant au sein de l'équipe). En qualité de coach agile, vous ne rédigez pas les user stories, mais vous devez être capable d’inspecter leur qualité. 🤓
La grille des critères INVEST va vous permettre de motiver les membres de votre équipe à modifier ou à mieux formuler l'énoncé d'une User Story. Ce concept agile vous assure que les User Stories ont bien les qualités requises pour figurer dans le Product Backlog. Une bonne User Story est :
Independent → Pas de dépendance entre les User Stories.
Negotiable → La User Story peut être arbitrée par le client et l'équipe.
Valuable → Un besoin est toujours associé à la User Story.
Estimable → L’équipe doit être en capacité d'estimer la User Story.
Small → La User Story est décrite précisément.
Testable → Les critères d’acceptation de la User Story sont atteignables.
Je vous conseille de prêter une attention particulière au cinquième critère (Small). Vous pourrez ainsi aider votre équipe à découper en plusieurs variantes une User Story trop large. ✂ ✂ Par exemple :
« En tant que joueur, je veux visualiser le plan du jeu d'évasion afin de m'orienter » :
« En tant que joueur, je veux visualiser ma position dans le jeu (...) » ;
« En tant que joueur, je veux visualiser un itinéraire dans le jeu (...) ».
Un bon découpage aura une influence réelle sur le déroulé du projet. C'est votre meilleure marge de manœuvre pour affiner les fonctionnalités du projet et anticiper les incertitudes de l'équipe.
Comment motiver les membres de l'équipe à découper leur User Story ? Quelles sont les limites de ce découpage pour constituer le Product Backlog ?
La motivation de votre équipe augmente lorsque l’aboutissement de son travail est concret. C'est pourquoi les user stories du projet se divisent toujours en courtes actions. La tâche représente alors le niveau de découpage élémentaire pour une User Story :
« En tant que joueur, je veux visualiser ma position dans le jeu afin de pouvoir m'orienter » :
- Intégrer un système de géolocalisation.
- Développer une carte numérique.
- etc.
C’est la bonne formulation des User Stories qui donnera toute sa fluidité à votre développement agile. 🌊 Votre client sera satisfait de comprendre l'avancée du travail en consultant le Product Backlog.
Les User Stories que vous avez prévu de gérer à une date lointaine sont décrites synthétiquement. Encouragez surtout votre équipe à détailler les tâches dont la réalisation est imminente. Vous pourrez alors évaluer la pertinence des tâches avec la grille de critères SMART :
Specific → Toute votre équipe comprend ce qu’il y a à faire.
Mesurable → Votre équipe sait comment s’assurer que la tâche est réalisée.
Achievable → Votre équipe dispose de tous les moyens pour réaliser la tâche.
Relevant → La tâche participe bien à la concrétisation de la user story.
Time Bound → La tâche a une durée de travail connue et limitée.
Vous ferez rapidement progresser les membres de votre équipe agile en respectant ces 5 critères lors de l'écriture des tâches. ☝ Je vous conseille aussi de bien surveiller le troisième critère, afin de limiter les causes de blocage pendant le développement : manque de connaissances, manque de matériel, etc.
Les deux grilles de critères (INVEST et SMART) que je viens de vous présenter sont des créations de l'auteur américain Bill Wake. Vous pouvez les utiliser librement avec votre équipe agile. Dans le chapitre suivant, je continue à vous montrer comment analyser en détail votre Product Backlog.
En résumé
Vous formalisez les besoins du projet en rédigeant des récits utilisateur (User Stories) qui répondent à 3 éléments descriptifs : qui, quoi et pourquoi.
En qualité de coach agile, vous inspectez les User Stories et les tâches grâce aux grilles de critères INVEST et SMART.
Parlons de là où vous allez pouvoir ranger vos User Stories dans le prochain chapitre : le Product Backlog.
