ou l’art de mettre ENFIN ses idées de produit puis ses User Stories à « l’épreuve du Feu ».
Ce que j’aime dans une approche LEAN STARTUP couplée fortement à l’UX (agileUX), c’est qu’elle permet aux Equipes, aux Product Owners et aux décideurs, non seulement de sortir du Monde des Opinions mais aussi de revenir aux premiers objectifs de l‘Agilité (à savoir Créer de la Valeur et Ravir le client) !
Des Hypothèses de nature différente… pour un Monde Incertain
Dans cet esprit, toute décision à prendre devient une hypothèse à tester.
Le format va rester le même mais la nature même des hypothèses à valider va évidemment varier selon l’avancement du projet, depuis l’existence même des problèmes jusqu’au choix des fines fonctionnalités de la solution…
- au départ, des Hypothèses relatives au(x) problème(s)
par exemple…
Nous croyons que le problème xyz existe chez notre Persona
Nous aurons raison si 80 % des personnes interrogées citent spontanément le problème (Problem Interview sur 30 personnes – Mode divergent)
Ce qu’on fait: On avance pour tester une solution à ce problème
.
Nous croyons que nos Early Adopter vont classer notre problème #1 comme leur problème #1
Nous aurons raison si 80 % des personnes interrogées classent notre problème en 1ère position (Problem Interview sur 30 personnes)
Ce qu’on fait: On avance pour tester une solution à ce problème
.
Nous croyons que le Persona principal se donne les moyens de résoudre le problème
Nous aurons raison si 80 % des personnes interviewés tentent ou ont tenté de résoudre ou contourner le problème
Ce qu’on fait: On propose un MVP
.
- des Hypothèses relatives au(x) cible(s) du produit (à vos PERSONAS)
par exemple…
Nous croyons que notre Persona principal existe
Nous aurons raison si nous pouvons identifier facilement 10 personnes lui correspondant dans la vraie Vie
Ce qu’on fait: On mise sur le Persona!!!
.
Nous croyons que notre Persona sera prêt à payer pour notre solution
Nous aurons raison si 8 clients signent une lettre d’intention (Prototype/ MVP)
Ce qu’on fait: On engage les développements
- des Hypothèses relatives aux fonctionnalités (User Stories)
par exemple…
Nous croyons que l’application sera utilisée majoritairement sur Mobile
Nous aurons raison si + 50 % des usages se feront à partir d’un mobile
Ce qu’on fait: Intensifier les dév. pour mobile
- des Hypothèses en termes d’usage, d’ergonomie de contenu…
par exemple:
Nous croyons que les articles Coaching sont sont plus consultés que les articles Facilitation ou Management
Nous aurons raison si les stats de lecture sont meilleures pour articles Coaching (Analytics)
Ce qu’on fait: Ecrire plus d’articles Coaching
Produire des Stories c’est bien, produire des Stories qui ont de la Valeur c’est mieux…
Une User story, cette exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur, est en principe source de VALEUR pour l’utilisateur ou le client final. Pourtant, force est de constater qu’un certain nombre de user stories ou fonctionnalités développées ne répondent toujours à ce critère de qualité…
Un bon moyen pour aller dans le sens de la Valeur pour l’Utilisateur est de se mettre dans une posture d’apprenant, d’émettre des hypothèses sur ces User Stories et de chercher à les valider au plus tôt, par exemple en allant recueillir à chaque sprint le feedback de vos Utilisateurs cible.
(Note: faire tester votre produit ou prototype à des personnes trop éloignées de votre Persona pourrait vous conduire à de mauvaises conclusions)
Un Exemple hypothèse:
Nous croyons que les critères de recherche avancés seront très utilisés
Nous aurons raison si… 100 clics par semaine (Analytics) / 80% des Testeurs se servent de la fonction (Tests Utilisateurs)
Ce qu’on fait: si OK, on garde les critères avancés
LA CLÉ :
INTÉGRER les hypothèses & Mesures dans les éléments de confirmation des User Stories!
Imaginez la User Story suivante:
En tant que Persona x,
je veux voir les logos A, B et C ainsi qu’un petit cadenas sur la Home
pour me rassurer sur mon inscription
Cette User Story, discutée entre le PO et son Equipe, s’accompagne d’éléments de conversation classiques (notamment des règles concernant les logos et d’une wireframe) ainsi que des conditions de satisfaction:
- Ce qui permettra au PO de qualifier la Story de Done
- Ce qui permettra à l’Equipe de la démontrer en Revue de sprint
Il s’agit maintenant d’ajouter à cette story nos hypothèses la concernant, ses objectifs chiffrés (résultat quantitatif mesurable ou résultat qualitatif observable), le type d’expérience qui permettra d’obtenir ce résultat (Tests Utilisateurs en cours de développement par exemple) et enfin l’action, l’apprentissage qu’on en tirera… Toute bonne mesure permet la prise de décision et entraîne une ACTION (c’est le caractère « Actionable » d’une bonne métrique).
Exemple d’hypothèses / mesures pour cette story:
Nous croyons qu‘ajouter des logos xyz sur la Home va rassurer la cible
Nous aurons raison si:
les logos sont positivement remarqués par n% des Utilisateurs (Tests Utilisateurs – Validation Intermédiaire) / si le nombre de signUp augmente de 30 % (Analytics validation finale)
Ce qu’on fait: Si OK on garde les Logos…on en ajoute potentiellement ailleurs (à tester)
D’autres exemples d’hypothéses / Mesures accompagnant des User Stories dans un Backlog de produit…
Nous croyons que l’application sera très utilisée en mode Hors Connexion
Nous aurons raison si n% de nos contenus sont lus Hors Connexion
Ce qu’on fait: Si OK, on développe les fonctions Hors Connexion
.
Nous croyons que la cible va comprendre facilement qu’il peut utiliser le menu pour accéder au contenu
Nous aurons raison si 80 % des utilisateurs réussissent la tâche sans erreur (Tests Utilisateurs) et 100% déclarent avoir compris l’interaction
Ce qu’on fait: on garde la forme du menu
Les TIPS Coaching
- Mettre en place un mur d’hypothèses… visualiser, montrer encore et toujours, transparence…
- Intégrer une démarche Persona Agile
- Intégrer les Hypothèses/ Mesure dans les description des User Stories
- Adosser le Post it Hypothése à la User Story sur le Taskboard
- Transformer ces « Hypothèses / Mesures » en scénarios de Test Utilisateurs au moment de la préparation de vos Plans de Test (pour chaque série de Tests Utilisateurs), ou en éléments de scripts pour vos Problem / Solution Interviews
Bref, Product Owners, Equipes Produit… lançons-nous et partons dans l’Aventure Produit!
Hello Jean-Claude,
Super article comme d’hab, un grand MERCI à toi!
Je me pose une question concernant la vérification de l’hypothèse. Dans le dernier exemple:
“Nous croyons que l’application sera très utilisée en mode Hors Connexion
Nous aurons raison si n% de nos contenus sont lus Hors Connexion
Ce qu’on fait: Si OK, on développe les fonctions Hors Connexion »
Il me semble manquer la façon dont on va tester cette hypothèse.
Dans ce cas, je pense qu’il faut au titre de la user story pouvoir proposer différentes options de solution d’imlémentation. Et dans l’approche lean startup, choisir celle qui dans un MVP pourra à moindre coût permetrre de valider l’hypothèse. Ensuite viendra le « ce qu’on fait »
J’ajouterai donc:
Nous croyons que « hypothèse »
Nous aurons raison si « critère de succès »
Nous le testons avec « une option »
Ce qu’on ferra « si l’hyptohèse est validée »
A+
Laurent.
Hello,
Merci de ton feedback. Ta proposition est une bonne option, l’autre étant d’indiquer entre parenthèse (ligne 2) le dispositif permettant de valider l’hypothèse.
Si le dispositif a un impact sur la façon d’implémenter la fonctionnalité; la nature de cet impact est de toute façon décrite dans la description de la User Story accompagnée par l’hypothèse & Mesure
A bientôt,
JC