Voir la source de Les Job Stories offrent une alternative viable aux User Stories

[[Category: User Story]]
[[Category: Job Story]]
[[Catégorie:Mike Cohn]]
[[Catégorie:Portail Product Owner]]
Auteur : Mike Cohn [[Fichier:MikeCohn.png|50px|link=https://twitter.com/mikewcohn]]<br/>
Source : [https://www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories Job Stories Offer a Viable Alternative to User Stories]<br/>
Date : 29/10/2019
----
Traducteur : Fabrice Aimetti<br/>
Date : 30/04/2020<br/>
----
Traduction :<br/>
<br/>
Aussi utiles que puissent être les [https://www.mountaingoatsoftware.com/agile/user-stories user stories], elles n'ont jamais été parfaites pour toutes les équipes. Une alternative intéressante pour certaines équipes est la ''job story''. Une job story est moins centré sur l'utilisateur qui réalise une certaine fonction et plus sur le travail à réaliser par cette histoire. Les job stories ont été créées à [https://www.intercom.com/blog/accidentally-invented-job-stories/ Intercom] et ont été expliquées par [https://www.intercom.com/blog/using-job-stories-design-features-ui-ux/ Alan Klement].<br/>

==Un modèle de Job Story==
Pour voir comment une job story fait glisser le curseur de l'utilisateur vers le travail à faire, regardons le modèle de job story préconisé :<br/>
<br/>
[[Fichier:Job-story fr.png|border|800px|link=]]<br/>
<br/>
Comme pour le [https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well modèle de user story] général, il y a trois parties à remplir dans le modèle de la job story. La première est connue sous le nom de ''situation''. Elle suit le mot ''lorsque'' dans le modèle et fournit un contexte sur le moment où l'histoire se déroule ou sur ce qui a peut-être déclenché l'histoire. Des exemples :
* Lorsqu'une commande est passée...
* Lorsqu'on fait une recherche par le code postal...
* Lorsqu'aucune réponse n'est trouvée...
* Lorsqu'on regarde les commandes récentes...
Le deuxième élément du modèle de la job story suit le modèle ''Je veux'' et fournit la ''motivation'' pour l'histoire. Considérez la motivation comme l'objectif déclaré ou de premier ordre d'un utilisateur.<br/>
<br/>
Par exemple, je veux une pizza pour le dîner de ce soir. Pourquoi est-ce que je veux de la pizza ce soir ? Parce que je retrouve des amis ce soir pour regarder un match de football, et qu'il est facile de nourrir avec une pizza un groupe comme le nôtre qui a des besoins et des préférences alimentaires différents. Dans le cadre de la job story, le fait de nourrir facilement un groupe est appelé le ''résultat attendu'' et il suit la partie "afin de" du modèle.<br/>
<br/>
Mettre mon désir de pizza dans une job story conduirait à :
* Lorsqu'il sera l'heure du dîner ce soir, je veux manger une pizza afin de pouvoir nourrir facilement mes amis.
Ce n'est pas une job story vraiment parfaite, mais elle illustre la différence entre la motivation d'un utilisateur et le résultat attendu.

==Comparaison entre Job et User Stories==
Pour voir à quel moment les job stories peuvent être meilleurs que les user stories, examinons quelques exemples de job stories et les user stories correspondantes.<br/>

===Lorsqu'une commande est passée===
Commençons avec la job story :<br/>
<br/>
'''Job Story :'''<br/>
Lorsqu'une commande est passée, je veux voir un message d'avertissement afin d'éviter de repasser la commande.<br/>
<br/>
Cette histoire décrit le comportement observé sur la plupart des sites de commerce en ligne avertissant un utilisateur pour qu'il ne passe pas une commande plusieurs fois.<br/>
<br/>
La user story équivalente pourrait être :<br/>
<br/>
'''User Story :'''
En tant que client, je veux qu'on m'affiche un message me disant de ne pas passer la commande deux fois afin de ne pas avoir une commande en double.<br/>
<br/>
La job story est meilleure dans ce cas pour deux raisons. Premièrement, cette histoire s'applique à toute personne effectuant un achat sur le site. Il n'est donc pas important de savoir que la personne qui fait cela est un client. (En fait, appeler la personne un client pourrait être trompeur car la personne ne peut pas être un client tant que cette commande n'a pas été passée).<br/>
<br/>
Deuxièmement, la job story est meilleure parce qu'elle fournit davantage de contexte sur le moment où cela se produit. Cela se produit "lorsqu'une commande est passée", comme nous le dit la job story. Regardez attentivement la user story et vous remarquerez qu'elle ne nous dit jamais quand ce message est affiché. L'équipe pourrait "réussir" à implémenter cette user story en ajoutant un élément sur une page de FAQ mettant en garde contre la double commande. Ce n'est presque certainement pas ce que souhaite le Product Owner.<br/>

===Lorsque je fais une recherche par le code postal===
Voyons maintenant un exemple de job story pour la recherche d'adresse par code postal américain.<br/>
<br/>
'''Job Story :'''<br/>
Lorsque je fais une recherche par code postal américain, je veux qu'on me demande d'entrer un code postal à 5 ou 9 chiffres afin de ne pas perdre de temps à chercher un code postal manifestement invalide.<br/>
<br/>
Il s'agit de s'assurer qu'un utilisateur saisit un code postal correct avant d'autoriser une recherche. Les codes postaux américains, ou ZIP, sont composés de 5 ou 9 chiffres. Cette histoire explique qu'il faut empêcher les utilisateurs de cliquer sur la recherche en ne saisissant que deux lettres dans le champ du code postal.<br/>
<br/>
La user story équivalente pourrait être :<br/>
<br/>
'''User Story :'''<br/>
En tant qu'utilsateur, je souhaite qu'on me demande d'entrer un code postal de 5 ou 9 chiffres afin de ne pas perdre de temps à chercher un code postal manifestement invalide.<br/>
<br/>
Ces deux histoires soulignent que la différence entre les user stories et les job stories existe dans la première partie des modèles. Les clauses Lorsque... et En tant que... diffèrent, mais dans cet exemple, le reste de chaque tory est identique dans le format de la user story et dans celui de la job story.<br/>
<br/>
Comme dans le premier exemple, la job story est meilleure ici en raison du contexte supplémentaire qu'elle fournit autour ''du moment où'' l'histoire se joue. La personne qui exécute l'action (la recherche dans ce cas) n'est pas importante, c'est pourquoi la user story est écrite avec le générique "En tant qu'utilisateur...".<br/>

==Quand utiliser les job stories==
En décidant du moment où il faut utiliser les job stories, je pense qu'il est important de reconnaître que les user stories et les job stories ont des points forts distincts.<br/>
<br/>
Je continue de trouver que les user stories sont les plus utiles pour les produits dont les utilisateurs varient considérablement et il est important de bien comprendre ces utilisateurs. C'est pourquoi les user stories commencent par En tant que... Nous commençons les user stories de cette façon parce que cela met l'utilisateur au premier plan. Dans le cas des user stories, ''la personne'' qui vivra l'histoire est peut-être aussi importante que ''ce qu'elle fera''.<br/>
<br/>
En revanche, pour une job story, il n'est pas nécessairement important de savoir qui vit l'histoire. Cela fait des job stories la meilleure option lorsque votre produit a des utilisateurs mais que leurs besoins ne sont pas très distincts.<br/>
<br/>
Si vous avez déjà écrit une longue série de user stories et commencé chacune par "En tant qu'utilisateur...", vous avez rencontré ce problème. Lorsqu'un grand nombre de user stories commencent toutes par "En tant qu'utilisateur...", vous avez un ensemble d'histoires pour lesquelles l'utilisateur n'est pas très important.<br/>
<br/>
Il serait utile de les écrire en tant que job stories plutôt qu'en tant que user stories. Cela permettrait d'inclure le contexte supplémentaire du moment où l'histoire est jouée. Dans certains cas, il est plus important de savoir quand une histoire pourrait se produire que de savoir qui va l'interpréter.<br/>

==Combiner les points forts des Job Stories et des User Stories==
Ainsi, bien que les job stories et les user stories aient chacune leurs propres points forts, il est possible de les fusionner et d'obtenir les deux avantages dans une seule histoire. Revoyons nos histoires de code postal et voyons comment faire. Tout d'abord, nous avons la job story :<br/>
<br/>
'''Job Story :'''<br/>
Lorsque je fais une recherche par code postal, je veux qu'on me demande d'entrer un code valide afin de ne pas perdre de temps à chercher un code postal manifestement invalide.<br/>
<br/>
Il n'est jamais évident de savoir qui interprète cette histoire. S'agit-il d'un utilisateur normal ? Un administrateur du site ? Quelqu'un d'autre ? On ne nous le dit jamais. Si nous pensons qu'il est important de savoir qui fait cela, nous pouvons compléter la job story en ajoutant un rôle à la place de Je. Cela change notre histoire qui devient :<br/>
<br/>
'''Job Story :'''<br/>
Lorsqu'il fait une recherche par code postal, '''un acheteur''' veut qu'on lui demande d'entrer un code valide afin que '''l'acheteur''' ne perde pas de temps à chercher un code postal manifestement invalide.<br/>
<br/>
Les changements sont en gras. Vous pouvez voir que je viens de passer de "je veux..." à "un acheteur veut..." et que j'ai ensuite effectué le changement correspondant plus tard dans l'histoire.<br/>
<br/>
Nous pouvons faire quelque chose de similaire avec la user story. Notre histoire initiale, non modifiée, était :<br/>
<br/>
'''User Story :'''<br/>
En tant qu'utilisateur je veux qu'on me demande d'entrer un code postal valide afin de ne pas perdre de temps à chercher un code postal manifestement invalide.<br/>
<br/>
Pour fournir un contexte supplémentaire, nous ajoutons une expression qui nous indique quand l'utilisateur fait cela. Notre histoire d'utilisateur modifiée devient alors :<br/>
<br/>
'''User Story :'''<br/>
Témoignage d'un utilisateur :
En tant qu'utilisateur '''qui effectue une recherche par code postal''', je souhaite qu'on me demande d'entrer un code postal valide afin de ne pas perdre de temps à chercher un code postal manifestement non valide.<br/>
<br/>
L'utilisateur modifié et les job stories sont sémantiquement les mêmes. Le choix vous appartient entièrement. Personnellement, je préfère la user story modifiée à la job story modifié parce qu'elle conserve l'article à la première personne. J'ai écrit ailleurs sur [https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-well les avantages des histoires à la première personne].<br/>

==Quand utiliser les job stories==
Alors, quand faut-il préférer les user stories ou les job stories ?<br/>
<br/>
Tout d'abord, chacune d'entre elles est excellente et a ses propres avantages. Tout au long de la semaine, j'écrirai quelques user stories et quelques job stories. Les deux techniques sont tout à fait compatibles et il n'y a aucune raison de les considérer comme mutuellement exclusives.<br/>
<br/>
Si votre produit a des utilisateurs et que leurs besoins diffèrent de manière importante, je vous suggère d'utiliser des user stories. L'accent supplémentaire qu'une user story met sur la personne qui effectue l'action peut permettre de mieux comprendre le comportement de l'utilisateur.<br/>
<br/>
Si, toutefois, les utilisateurs de votre produit ne diffèrent pas de manière significative, les job stories sont probablement la meilleure approche.<br/>
<br/>
Un bon point de départ consiste à mélanger les user stories et les job stories dans le même backlog produit. Commencez par rédiger des job stories chaque fois que vous êtes tenté d'écrire un paquet d'histoires commençant tous par "En tant qu'utilisateur...".<br/>

==Quelle est votre propre expérience ?==
Que pensez-vous des job stories ? Seraient-elles utiles pour votre backlog produit ? Avez-vous déjà travaillé avec des job stories ? Ont-elles été utiles ? Je vous invite à me faire part de vos réflexions dans la section "Commentaires" ci-dessous.