Hypothèses et Mesures pour vos Problèmes et vos User Stories

lean startup mesures

ou l’art de mettre ENFIN ses idées de produit puis ses User Stories à « l’épreuve du Feu ».

Hypotheses-Mesure Lean Startup

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 lAgilité (à 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!

Format Hypotheses Lean Startup

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

Mur des Hypothéses Lean Startup

  • 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!

A propos de jc-Qualitystreet (Jean Claude Grosjean) 452 Articles
Jean Claude GROSJEAN - COACH d’Organisation. Coach d'Equipes - Coach Agile. J’accompagne la transformation des organisations et coach les PERSONNES, les EQUIPES dans leur nouveau parcours. La facilitation & la formation font aussi partie de mes activités. Me contacter: 06.20.98.58.40

2 Comments

  1. 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.

  2. 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

1 Trackback / Pingback

  1. Hypothèses et Mesures pour vos Probl&egr...

Les commentaires sont fermés.