Nous vous proposons dans cet article une méthode simple vous permettant de cibler le contenu de votre première version logicielle, et de prioriser les fonctionnalités les plus importantes.
En tant que Product Owner, présentez votre vision, récoltez les avis de vos utilisateurs et mesurez les indicateurs de valeur métier, pénalités et risques.
|
Le matériel nécessaire pour ce jeu
· Post-it de différentes couleurs · Feutres qui fonctionnent bien · Plusieurs feuilles de Paper Board à coller au mur (une par équipe et par session) · Du scotch · Optionnel : Jetons de Poker de 3 couleurs différentes
|
|
Durée optimale : 1h30
|
Les étapes du jeu sont les suivantes :
- La présentation des fonctionnalités par le responsable du produit, et la mise en évidence des Personas, qui sont les parties prenantes de votre application.
- Deux séances participatives en équipes, permettant de rendre compte des avis des participants et de mettre en évidence les priorités applicatives.
- Une synthèse collective qui permettra à l’équipe de développement d’effectuer l’évaluation de la complexité, de prioriser les User Stories et lancer la phase de rédaction.
Chaque étape est limitée dans la durée : afficher clairement le temps alloué au début de chaque action et veiller à son respect même si les actions ne sont pas terminées.
Etape n°1 : La présentation des fonctionnalités et la mise en évidence des Personas
- Durée recommandée : 15 minutes à 1 heure -
Le Product Owner liste les fonctionnalités du projet et affiche un post-it pour chacune, puis les présente en détail à l’oral ; dans notre cas de figure qui est un petit projet, les fonctionnalités présentées sont déjà des User-Story.
Utilisez les post-it bleus pour vos User Story et affichez les dans un ordre cohérent d’expérience utilisateur.
Note : dans le cas de macro fonctionnalités nous parlerons d’Epics, qui seront-elles-mêmes découpées en User Stories.
|
Définissez vos User Story selon les critères INVEST
· I pour Independant. Chaque US doit être indépendante des autres, ce qui permettra de modifier la priorité d’une US sans impacter les autres. · N pour Negociable. Les US doivent pouvoir être négociées par l’équipe : elles se concentrent sur l’essence de la fonctionnalité, et ne présente par un contrat détaillé de la mise en œuvre (notamment technique.) · V pour Valuable (Précieux). Votre US doit avoir de la valeur métier. · E pour Estimable. La US doit être estimable en complexité par l’équipe ; si la story est trop large pour être estimée, nous la considérons alors comme une Epic, qui sera découpée en User Stories. · S pour Small (Petit), permettant de la réaliser en un temps raisonnable. · T pour Testable. La finalisation de la User Story par l’équipe de développement doit se mesurer car des critères quantifiables, qui seront établis par le Product Owner et fournis à l’équipe de développement en entrée de Sprint (conjointement aux résultats attendus des tests spécifiés).
|
Le Product Owner liste les parties prenantes (les Personas) de votre produit. Par exemple : les agriculteurs, les conseillers agricoles, l’administrateur de données.
Utilisez les post-it jaunes pour lister les Personas.
Votre tableau affiche désormais les User Stories dans un parcours utilisateur cohérent (de gauche à droite) ainsi que les Parties Prenantes dans le coin supérieur droit.
Etape n°2 : Jeu collaboratif
- Durée recommandée : 30 à 45 minutes en fonction du nombre d’équipes -
|
Matériel et Organisation
Chaque participant : · Dispose de post-it et feutres · Reçoit 20 points de Valeur Métier, 10 points de Pénalités et 10 points de risque (le nombre de points est à adapter en fonction du nombre de participants) · Intègre une équipe de 2 à 5 personnes. Il est intéressant d’avoir 3 à 4 équipes.
Les jetons de poker peuvent être remplacés par des points ou barres tracées au feutre sur chaque US : couleur verte pour les points de valeur métier, couleur bleue pour les pénalités et rouge pour les risques.
|
Le Product Owner présente la signification des points :
La valeur métier correspond à l’apport de la fonctionnalité pour la partie prenante considérée qui est l’utilisateur final. Lorsque le logiciel est destiné à plusieurs types d’utilisateurs finaux, le travail est à faire pour chaque partie prenante, ce qui peut être réparti sur les différentes équipes constituées.
Les pénalités correspondent au montant induit si la fonctionnalité n’est pas implémentée. Par exemple pour une application à 100 €, j’estime à 1€ la pénalité de ne pas avoir la User Story de tutoriel, et à 50 € la pénalité de ne pas avoir la User Story de création de compte utilisateur.
Les risques sont l’évaluation de la capacité à atteindre la satisfaction client avec la mise en place de cette User Story. Par exemple, la mise en place d’une fonctionnalité de compte est peu risquée, car simple à définir ; en revanche la présentation de tutoriels volumineux dans une application mobile peut être risquée car apporte lourdeur à l’application, tout en étant pas assurée que l’utilisateur final utilise la fonctionnalité.
Round n°1 : Durée 10 minutes
- L’équipe reproduit sur sa table les User Stories affichées au tableau par le Product Owner
- Le Product Owner précise pour quelle(s) partie(s) prenante(s) le jeu s’applique
- Chaque participant répartit ses points de valeur métier, de pénalités, de risques sur les différents post-it en faisant des commentaires au reste de l’équipe.
- L’équipe synthétise ses remarques sur des post-it verts, verticalement en 3 catégories : valeur métier, pénalités, risques.
Round n°2 : Durée 2 minutes
Chaque participant reprend ses jetons et les répartit à nouveau sur les User Stories, sans faire de commentaires.
Restitution : 5 minutes par équipe
- Un représentant de chaque équipe donne au Product Owner les totaux de son équipe en points de valeur métier, de pénalités, de risques. Le Product Owner fait la somme des points des équipes.
- Le représentant se dirige au tableau commun et affiche les post-it de l’équipe en les commentant. Les post-it sont positionnés de manière à correspondre à la User Story affichée à la verticale.
Votre tableau final a l’allure finale suivante, prenez-le en photo et communiquez là à tous les participants. Indiquez aux participants les prochaines étapes :
- La prise en compte des remarques émises et la mise à jour des User Story
- L’évaluation par l’équipe de développement de la complexité des User Story
- La priorisation des User Story
Note : cet article a été rédigé dans le contexte d’un projet, n’hésitez pas à l’adapter à votre besoin.
Par Nicolas Minary, Neolusis (www.neolusis.fr).