Écrire de meilleures “User Stories” avec le concept de “Jobs-to-be-done”

Le terme de “Job Story” se fait de plus en plus entendre au sein des équipes produit. C’est une alternative au format classique des User Stories qui a pour objectif de nous aider à comprendre ce qui motive le client à utiliser notre produit.

Ce format permet de mieux décrire les besoins de l’utilisateur et le contexte dans lequel il va utiliser le produit. Il favorise l’empathie que le PO et l’équipe de développement ont pour l’utilisateur et ouvre donc la porte a l’élaboration de solutions à plus forte valeur ajoutée que celles qui auraient été élaborées à partir du format classique des User Stories.

Plus concrètement – l’exemple de zoom

Les Jobs Stories se basent sur un concept appelé jobs-to-be-done. Dans le concept des jobs-to-be-done, on considère qu’un utilisateur embauche un produit ou une fonctionnalité en vue d’un job particulier. 

Par exemple, j’embauche l’application Zoom pour faire le job de « me connecter et échanger avec des personnes qui ne sont pas au même endroit que moi». On considère que les utilisateurs se comportent avec un produit comme le ferait un recruteur avec un candidat. Ils recherchent le produit capable de « faire le job » (en l’occurrence, connecter et échanger à distance) et « embauchent » ce produit (en l’occurrence l’application Zoom). Le produit n’est jamais une finalité.

Le contexte a beaucoup d’influence sur la solution optimale qu’un utilisateur va “embaucher” pour faire le job. Prenons par exemple ces deux contextes. 

Dans le premier contexte, un organisateur événementiel veut organiser une conférence de 3 jours en ligne pour 600 personnes. 

Dans le deuxième contexte, un psychologue veut organiser des appels en visio de manière régulière avec un seul patient à la fois. 

Dans les deux cas, le job-to-be-done est le même (connecter et échanger à distance) mais la solution optimale qui répondra à leurs besoins sera différente. Il est donc primordiale de comprendre le contexte dans lequel le job sera à faire car la solution idéale pour faire ce job dépend des caractéristiques du contexte.

Comparons User Story classique et Job Story

Si on reprend l’exemple de ZOOM

Format classique des User Stories:

En tant qu’organisateur
Je veux une fonctionnalité me permettant de faire une annonce à tous les participants de la conférence en même temps
Afin de partager des information urgentes et importantes le plus vite possible.

Format Job story:

Quand les participants de la conférence en ligne sont séparés dans différentes salles virtuelles en parallèle
J’ai besoin de pouvoir faire une annonce à tous les participants en même temps, depuis la salle de conférence où je suis et sans avoir à rentrer et ressortir de chaque salle de conférence
Afin de partager des information urgentes et importantes le plus vite possible.

L’information “En tant que” peut être ajoutée aux Job Stories afin de préciser qui est l’utilisateur si nécessaire.

Un autre exemple

Voici une autre comparaison entre une User Story classique et Job story. Un Product Owner avait utilisé le format classique des User Stories pour décrire un Epic :

En tant que Marketing Manager

Je veux un dashboard pour consulter les performances de mes anciennes campagnes publicitaires 

afin maximiser le succès de mes prochaines campagnes publicitaires

En voulant transformer cet Epic dans le format d’une Job Story, le PO a davantage questionné le Marketing Manager sur le contexte d’utilisation du dashboard et s’est rendu compte qu’il y avait en fait deux contextes distincts dans lequel le dashboard allait être utilisé et donc deux Job-to-be-done distincts. L’Epic initial a donc été transformé en deux Epics. Les voici dans le format d’une Job Story:

Epic 1:

Quand je lance une nouvelle campagne publicitaire,

J’ai besoin de différentes informations de mes campagnes passées telles que:

– Le Cost per Action selon la tranche d’âge de l’audience
– Le reach selon le moment de la journée
– (etc)

afin de maximiser le succès de mes prochaines campagnes publicitaire

Epic 2:

Quand je crée le rapport bilan chaque mois pour mes supérieurs

J’ai besoin d’un pdf avec:

– graphique Y-Z

– graphique W-L

– graphique D-Y

Afin de perdre le moins de temps possible à élaborer le document

En conclusion

Le format Job story est intéressant car il pousse les équipes à davantage échanger et raisonner sur 1) ce qui motive l’utilisateur, 2) ce dont il a besoin dans un produit pour “faire le job” et 3) sur le contexte dans lequel il va utiliser le produit. Ce format amène par consequent les équipes à développer des solutions plus innovantes et ayant plus de valeur ajoutée pour l’utilisateur.