Job Stories

Objectif

Une job story décrit un élément du backlog produit comme un travail à accomplir par une partie prenante dans un moment donné. La phrase nomme la situation qui déclenche le besoin, ce que la personne cherche à obtenir à cet instant et le résultat qu'elle en attend. L'expression job to be done, la tâche que quelqu'un cherche à faire aboutir, vient de la théorie de la demande formulée par Clayton Christensen: on « engage » un produit pour accomplir un travail, et ce travail explique l'achat mieux que le profil de l'acheteur.

Le format traite un défaut de conception: une exigence attribuée à un rôle dit qui agit sans dire pourquoi. Deux personnes que rien ne rapproche démographiquement rencontrent le même déclencheur et veulent la même chose; une même personne rencontre ce déclencheur dans des rôles différents selon le jour. Klement a formulé l'argument en 2013 contre la persona, ce portrait type d'utilisateur construit sur des traits démographiques et comportementaux: un client imaginaire dont les traits n'expliquent aucune causalité. La situation porte le contexte du moment, matière dont l'équipe de livraison se sert pour concevoir.

Le livrable est la phrase elle-même, posée sur le backlog et raffinée comme tout autre élément.

Usage

Quand l'utiliser

• Besoin déclenché par un moment précis: ce qui provoque l'action pèse plus lourd que l'identité de qui agit.
• Situation partagée par plusieurs rôles: un seul déclencheur porte des motivations distinctes.
• Conception d'expérience utilisateur: la situation livre les contraintes du moment.
• Backlog qui dérive vers la solution: le format oblige à énoncer le besoin avant toute fonctionnalité.
• Raisonnement de cause à effet: relier un déclencheur à un résultat attendu, puis vérifier si le résultat s'est produit.
• Raffinement dans l'équipe de livraison: le format se pratique sur des éléments déjà inscrits au backlog.

Quand ne pas l'utiliser

• Habilitations à spécifier: la phrase tait le rôle, donc les droits d'accès, prendre une matrice des rôles et permissions.
• Comportement riche en chemins alternatifs: trois segments ne portent ni flux ni exceptions, prendre les cas d'utilisation.

Description

La forme de la phrase

La job story s'écrit à la première ou à la troisième personne. La première fait parler la partie prenante: « quand situation, je veux motivation, afin de pouvoir résultat attendu ». Elle se lit de gauche à droite comme une chaîne causale: un déclencheur, un besoin qu'il éveille, un état que la personne veut atteindre.

Les trois éléments

La situation donne le contexte du moment où le travail doit s'accomplir. Elle nomme un déclencheur et ce qui l'entoure: ce qui vient d'arriver, ce qui presse, ce qui est ignoré, où se trouve la personne. Plus le contexte est fourni, mieux l'équipe conçoit.

La motivation nomme ce que la partie prenante cherche à obtenir. Elle admet les forces internes, l'inquiétude, la hâte, l'habitude, comme les forces externes, un délai, une facture, un tiers qui attend. Le format en écarte la fonctionnalité: écrire « je veux un bouton sur l'écran d'accueil » ferme la conception, et l'équipe hérite d'une solution.

Le résultat attendu dit ce qui satisfait la motivation ou ce qui l'apaise. Il se formule comme un état que la personne atteint, ce qui le rend observable une fois la solution livrée.

Une situation, plusieurs acteurs

Un même déclencheur mobilise parfois plusieurs personnes aux besoins différents. Leurs rôles entrent alors dans le segment « quand » et la phrase passe à la troisième personne: « quand quelqu'un situation, acteur veut motivation, afin que résultats attendus ». La situation reste unique et les motivations se démultiplient, une par acteur, avant de converger vers un résultat commun. En user story, un rôle par carte impose d'écrire autant de cartes que de rôles et laisse le lien entre elles implicite.

Écrire une job story

1. Recueillir la situation sur le terrain
   Le déclencheur est une donnée empirique. Il vient d'un entretien, d'une observation en situation de travail, d'un ticket de support ou d'un enregistrement d'usage. Une situation écrite depuis le bureau est une hypothèse déguisée en fait.
2. Écrire le contexte avec les mots de la personne observée
   Le vocabulaire de projet lisse ce qui fait la contrainte: « le système est lent » a remplacé « j'ai trois patients qui attendent au comptoir ».
3. Remonter de la fonctionnalité au besoin
   Quand la personne interrogée demande un écran, un bouton ou un rapport, on lui demande à quoi il servirait et on écrit la réponse. La motivation est ce qui reste quand plus aucun objet d'interface n'est nommé.
4. Nommer le résultat attendu et la donnée qui le constate
   Un résultat que rien ne permet d'observer ne sera jamais vérifié: on nomme du même coup où l'effet se lira, décompte, journal d'usage ou volume d'appels.
5. Faire relire la phrase par une personne de chaque rôle concerné
   Un déclencheur partagé se confirme là: chaque rôle reconnaît le moment et corrige sa propre motivation. La phrase passe alors à la troisième personne.
6. Poser la phrase au backlog et la décomposer
   Une job story se découpe en job stories plus petites, qui reprennent chacune le circuit de raffinement et de priorisation.
7. Attacher les critères d'acceptation avant l'estimation
   Le format n'en fournit pas, donc l'équipe choisit la forme: exemples exécutables, liste de conditions ou critères d'acceptation classiques. Ce choix se tranche une fois pour tout le backlog.

Job story ou user story

Les deux formats occupent la même place sur un backlog et diffèrent par un seul segment, le premier. Les segments suivants gardent la même fonction.

La situation est le bon premier segment quand le moment du déclenchement commande ce qui sera construit: conception d'interaction, parcours partagé entre plusieurs profils, question du « pourquoi maintenant ». Le rôle le redevient dès qu'il faut documenter une délimitation des droits d'accès ou tenir une vérification disciplinée. La user story arrive alors avec INVEST.

L'Agile Extension prévoit qu'ils cohabitent: la job story porte la motivation et le résultat attendu, la user story porte la fonctionnalité candidate. Le guide en énonce le risque: une équipe qui s'égare en passant d'un format à l'autre. En pratique, on réserve un format à une phase, la découverte par exemple, plutôt que de mêler les deux dans une file unique.

Ce qui fait échouer une job story

La persona réintroduite dans la situation

« Quand je suis administrateur du système » place un rôle dans le segment de la situation. Y écrire qui est la personne ramène le biais de la persona que le format écarte.

La solution glissée dans la motivation

« Je veux un export CSV » a l'air d'une motivation et la phrase reste bien formée; c'est une commande de fonctionnalité qui ne laisse plus rien à concevoir.

La phrase qui enfle

Le format est plus verbeux que la user story, puisqu'il porte le contexte, les acteurs et les résultats. Passé trois lignes, la job story cesse d'être lisible en réunion de raffinement. Le contexte se garde à ce qui change une décision de conception.

Le résultat attendu qui reformule la motivation

« Je veux connaître mon solde afin de pouvoir connaître mon solde » est un segment perdu. Le résultat attendu se situe au-delà de l'application, dans ce que la personne décide ou évite grâce à elle.

La décomposition laissée sans suite

Une job story de bonne taille se découpe en cinq ou six phrases plus petites. Chacune arrive sur le backlog avec sa priorité à fixer et son raffinement à mener; sans cette gestion, le découpage allonge la file sans rien clarifier.

Les critères d'acceptation jamais écrits

Le format n'en demande aucun. Une équipe qui l'adopte sans y penser se retrouve avec des phrases riches en intention dont personne ne sait dire si elles sont satisfaites.

Considérations IA

Un modèle rend trois services sur ce format. Il convertit un corpus: un lot de user stories, de tickets de support ou de verbatims d'entretien devient une liste de candidats pour les trois segments, que l'équipe corrige ensuite. Il contrôle mécaniquement ce que le format ne contrôle pas, en signalant la fonctionnalité glissée dans le segment motivation, le rôle déguisé en situation ou le résultat attendu qui reformule la motivation; ces défauts sont de forme. Il varie les situations: à partir d'un déclencheur observé, il propose les variantes du même moment sous d'autres contraintes, la nuit, sans réseau, en déplacement, que l'équipe retient ou écarte.

Les limites tiennent à la matière du premier segment. La situation est une donnée de terrain: un modèle produit des déclencheurs plausibles que personne n'a vécus, et une job story bâtie sur un moment inventé recrée le biais de la persona. Les inquiétudes et les frictions que la motivation doit porter viennent de clients réels, entendus ou observés; générées, elles ne décrivent que les régularités du corpus d'entraînement. La priorisation reste une décision métier, portée par la valeur et la fréquence propres à cette organisation. Enfin, tickets de support et verbatims d'entretien portent des données personnelles au sens de la LPD, souvent des données de santé ou de finances, et ne partent pas dans un service public sans base légale ni anonymisation.

Exemples

Une caisse maladie envisage d'ajouter à son application le suivi de la franchise consommée. Des entretiens en agence font remonter un même moment: le médecin propose un traitement qui peut attendre, et l'assuré ne sait pas où en est sa franchise annuelle. Le besoin s'écrit alors en une phrase.

« Quand mon médecin me propose en novembre un traitement non urgent et que j'ignore où en est ma franchise annuelle, je veux voir la part déjà consommée et le reste à ma charge si je commence maintenant, afin de pouvoir décider si je fixe le rendez-vous cette année ou en janvier. »

La situation court jusqu'à « franchise annuelle » et porte tout ce qui rend la décision possible. La motivation tient dans les deux montants que l'assuré cherche, sans nommer l'écran qui les lui montrera. Le résultat attendu est la date qu'il fixera.

Un assuré de trente ans et un retraité vivent cette situation à l'identique, si bien que l'écran à concevoir est le même pour les deux. Une user story aurait dû choisir un rôle, distinction sans effet sur la conception.

Sous la LAMal, la franchise se remet à zéro le 1er janvier: l'assuré qui l'a déjà atteinte ne paie plus que la quote-part jusqu'au 31 décembre, et repousser le soin le fait repartir sur une franchise entière. Un suivi lisible du solde concentre donc les soins non urgents de ces assurés sur les dernières semaines de l'année, effet que la caisse lit dans ses décomptes. La motivation, elle, s'arrête au besoin et laisse ouvertes plusieurs solutions: une notification en novembre, un simulateur de participation aux coûts, un rappel dans le décompte trimestriel.

Visualisations

Le cas multi-acteurs est un branchement, une situation vers plusieurs motivations puis un résultat commun, forme qu'aucune énumération ne rend. La comparaison avec la user story est une permutation de position, qui se dessine en alignant les deux phrases segment par segment. La technique produit enfin une phrase segmentée, des blocs étiquetés: la carte de job story montre les trois segments et ce que chacun porte. Les différences de fond entre les deux formats, en revanche, sont faites de lignes et de colonnes et se rendent en tableau.

Coût

Outils

La job story est une convention d'écriture, donc l'outil est le support où la phrase vit. Le tableau blanc et les notes autocollantes suffisent en atelier, avec un gabarit en trois bandes tracé une fois pour toutes: la contrainte visuelle des trois segments fait apparaître le segment bâclé. Les tableaux collaboratifs (Miro, Mural, FigJam) tiennent le même rôle pour une équipe dispersée et conservent les variantes d'une situation côte à côte.

Les outils de gestion de backlog (Jira, Azure DevOps, GitLab) accueillent la phrase dès qu'elle doit être priorisée, estimée et reliée à ce qui la satisfait. Deux réglages y suffisent: un modèle de ticket qui impose les trois segments comme champs distincts plutôt qu'un bloc de texte libre, ainsi qu'une étiquette qui distingue les job stories des user stories quand les deux formats cohabitent. Les segments deviennent alors filtrables, ce qui permet de retrouver tous les éléments du backlog attachés à une même situation.

Les outils de recherche utilisateur et les plateformes de support (Dovetail, Zendesk) sont en amont la source des situations, puisqu'ils gardent les verbatims où les déclencheurs apparaissent. Aucun outil n'est requis: trois segments écrits au feutre sur une bande de papier sont une instance complète de la technique.

Sources

• IIBA, Agile Extension to the BABOK Guide, §7.4 Job Stories: la définition, la première et la troisième personne, les trois éléments (situation, motivation, résultat attendu), les forces du format et ses limites, dont la verbosité, la décomposition à gérer et la confusion entre formats sur un même backlog.
• Alan Klement, Replacing The User Story With The Job Story, 2013: l'origine du terme et de la phrase en trois segments, avec l'argument contre la persona.
• Paul Adams, Designing Features Using Job Stories, Intercom: la version appliquée à la conception de fonctionnalités, dans la forme « quand, je veux, afin de pouvoir » que l'Agile Extension reprend.
• Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan, Know Your Customers' Jobs to Be Done, Harvard Business Review, 2016: la théorie des Jobs to Be Done dont le format hérite.