Remarque : le site a été traduit automatiquement. Passe à l'anglais pour une expérience de lecture optimale.

Qu'est-ce qu'une histoire d'utilisateur en agile ?

Histoires d'utilisateurs dans Scrum : tout ce que tu dois savoir

L'objectif est clair : tu veux développer un produit qui apporte une grande valeur ajoutée aux clients. Tu veux obtenir un résultat qui satisfasse les membres de l'équipe et les parties prenantes. Mais comment atteindre cet objectif ? Comment peux-tu répondre à toutes les exigences d'un produit en procédant par petites étapes approfondies ? 

En Agile, les User Stories se sont avérées être un outil efficace. Elles t'amènent petit à petit de l'idée initiale au produit prêt à être vendu. Je te montre ce que sont les User Stories, comment tu les crées et comment tu peux en profiter.

 

Que sont les User Stories dans Agile ?

La définition des User Stories en Agile décrit les exigences d'un produit du point de vue de l'utilisateur. En d'autres termes, les histoires d'utilisateurs te disent quelles caractéristiques et fonctions un produit doit avoir. Elles sont donc un outil central pour discuter des besoins des utilisateurs, les valider et travailler à leur réalisation avec une compréhension commune. 

Les User Stories offrent un langage universel que les membres de l'équipe, les parties prenantes et les clients comprennent et parlent. Dans la pratique, cela signifie que tu peux utiliser les User Stories pour développer une compréhension du produit souhaité par le client qui laisse peu de place aux malentendus. 

Plusieurs histoires d'utilisateurs forment ensemble un cas d'utilisation. Les User Stories trouvent leur origine dans le développement logiciel Agile.

 

Comment sont structurées les histoires d'utilisateurs agiles ?

Les histoires d'utilisateurs décrivent les exigences et les souhaits d'un résultat de projet à créer du point de vue du client ou de l'utilisateur. Pour cela, les histoires d'utilisateurs agiles disposent de cette structure élémentaire :

QUI (rôle), veut QUOI (objectif/désir) POURQUOI (valeur ajoutée) ?

Regardons de plus près les différents éléments des User Stories :

QUI (UTILISATEUR)

Tu remplis l'espace réservé WER avec ton client ou un représentant typique de ton groupe cible. Le niveau de détail de la description du WER dans la User Agile Story dépend d'une part de la User Story elle-même et d'autre part de l'avancement du projet. Sois donc suffisamment détaillé pour obtenir une User Story pertinente.

QUOI (FONCTIONNEMENT)

C'est ici que tu places les souhaits de l'utilisateur. Pour cela, tu peux te demander ce que l'utilisateur attend ou ce dont il a besoin. Si ton produit se trouve encore dans une phase de développement précoce, tu peux formuler des hypothèses sur les fonctions attendues par l'utilisateur en te basant sur ton expérience. Si tu as déjà un produit similaire sur le marché, tu peux aussi déduire les fonctions souhaitées à partir du feedback sur ce produit.

POURQUOI (VALEUR AJOUTÉE)

Seule la valeur ajoutée montre pourquoi une fonction est importante pour l'utilisateur. Le POURQUOI te permet donc de réfléchir honnêtement à ta connaissance des besoins d'un client. Car : inclure une exigence dans une User Story est facile – par exemple, parce que le client en exprime le souhait. Mais ce n'est que lorsque tu comprends pourquoi le client en a besoin que tu disposes du contexte pour la réalisation de l'exigence. Ce n'est qu'à ce moment-là que tu peux te demander si la proposition/le souhait du client répond efficacement à son besoin réel – ou si, le cas échéant, il existe un moyen plus intelligent. Prenons un exemple : 

Le client souhaite une cape de pluie pour faire du vélo. Tu pourrais donc inclure maintenant l'exigence "cape de pluie". Ou tu peux demander au client pourquoi il a besoin d'une cape de pluie. Disons que le client répond "parce que je ne veux pas me mouiller". 

Cela signifie que tu ne dois pas nécessairement fournir une cape de pluie. Tu peux aussi fournir un vélo avec un toit intégré. L'essentiel est que le besoin ou le problème du client soit ainsi résolu –, à savoir ne pas se mouiller. Plus tu comprends le "pourquoi", mieux tu peux concevoir ton histoire d'utilisateur.

La plupart des coachs Agile tournent en rond...

...et traiter les symptômes superficiels. Il est temps d'utiliser la psychologie – pour un changement d'état d'esprit durable.

"Beaucoup de membres de l'équipe n'osent pas ouvrir la bouche !"

"Nous découvrons trop de problèmes et de bugs inattendus à un moment tardif !"

"Pourquoi me faut-il parfois des heures pour préparer une simple rétrospective ?"

Que sont les User Stories dans Agile (exemple) ?

Tu connais maintenant les différents éléments des User Stories Agile. Un exemple de User Story Agile peut ressembler à ceci : 

En tant que CLIENT je voudrais UN MOT DE PASSE SÛR, POUR QUE LES DONNÉES DE MES CLIENTS SOIENT PROTÉGÉES.

Voici le "CLIENT" l'utilisateur, "UN MOT DE PASSE SÛR". la fonction et "POUR QUE LES DONNÉES DE MES CLIENTS SOIENT PROTÉGÉES". la valeur ajoutée. 

 

Que sont les User Stories dans Scrum ?

Si tu travailles avec des user stories dans Scrum, tu les complèteras par ce que l'on appelle des critères d'acceptation. Les critères d'acceptation décrivent les exigences techniques auxquelles les user stories doivent répondre au moment de l'acceptation. En d'autres termes, tu peux le dire : Les critères d'acceptation sont les conditions dont tu as besoin pour qu'une User Story crée de la valeur.

L'importance des User Stories Agile dans le backlog peut être plus nuancée. Car : dans les backlogs, les user stories peuvent non seulement décrire des exigences, mais aussi représenter un type de hiérarchie spécifique. Il existe 3 types de hiérarchie :

Epics : Les épics sont de vastes domaines fonctionnels d'un produit dont la portée concrète peut encore être floue.

Caractéristiques : Les fonctionnalités sont des caractéristiques de performance spécifiques au sein d'une épopée.

Des histoires : Les stories sont des histoires d'utilisateurs agiles techniques et des histoires d'utilisateurs au sein d'une fonctionnalité.

Tu peux mettre en œuvre ces types de hiérarchie en un seul sprint. Tu crées un avantage concret pour l'utilisateur. 

 

Écrire des user stories – Comment créer des user stories convaincantes ?

Pour écrire des User Stories utiles dans la gestion de projet agile, il est essentiel d'avoir des discussions approfondies avec toutes les personnes concernées. Celles-ci doivent te permettre de bien comprendre le groupe cible et le produit à créer. Tu peux ensuite en déduire des personas, par exemple. 

En outre, les soi-disant Critères INVESTIl est important que tu saches qu'il n'y a pas d'autre moyen de mettre sur pied une histoire d'utilisateur convaincante :

Indépendant : Une User Story doit être indépendante des autres User Stories. Cela signifie que la mise en œuvre d'une story ne doit pas présupposer qu'une autre story a été mise en œuvre auparavant. L'avantage est que tu peux à tout moment donner la priorité aux user stories ou les retirer du backlog. 

Pour cela, regardons à nouveau l'exemple du vélo. Disons que tu as décidé d'installer un petit toit sur la selle du vélo au lieu d'une cape de pluie pour que le client ne soit plus mouillé. Ce serait donc une User Story. Mais tu réalises maintenant que pour avoir un toit, tu dois d'abord développer une selle plus solide à laquelle le toit peut être fixé. Mais ce serait une autre User Story. Les deux stories se basent l'une sur l'autre. C'est exactement ce que tu dois éviter.

Bien sûr, il est parfois inévitable que tu doives réaliser une User Story avant une autre. Mais évite toujours les user stories pour lesquelles tu dois d'abord réaliser 20 autres user stories.

Négociable : L'écriture d'une histoire d'utilisateur peut parfois prendre beaucoup de temps – mais elle ne doit pas pour autant être gravée dans la pierre. Cela signifie : Propriétaire de produit, les parties prenantes et les développeurs devraient toujours discuter ensemble d'une User Story et la préciser. 

Valuable : Le résultat des User Stories dans la gestion de projet agile doit avoir une valeur ajoutée pour le client.

Estimable : Une histoire d'utilisateur convaincante permet à l'équipe de développement d'estimer l'effort nécessaire pour la réaliser.

Small : Une User Story doit être suffisamment "petite" pour être réalisable en un sprint.

Testable : Les User Stories dans Scrum devraient pouvoir être testées. C'est la seule façon de vérifier qu'elles peuvent être mises en pratique.

 

Voici comment tu peux profiter des User Stories en Agile

Si tu n'es pas encore familier avec l'écriture d'histoires d'utilisateurs en Agile, cela peut te sembler être du travail supplémentaire. Cependant, les histoires d'utilisateurs fournissent aux équipes un contexte important pour leurs tâches et soulignent ainsi l'importance de chacune d'entre elles.

En principe, tu profites ainsi des User Stories :

Focus sur l'utilisateur : Les User Stories sont comme une liste de choses à faire orientée vers les problèmes. Elle permet à ton équipe de garder un œil sur ses tâches et de savoir exactement comment répondre aux besoins des utilisateurs.

Une collaboration globale : Les User Stories permettent à tous les participants de voir d'un coup d'œil où ils vont. De cette façon, tout le monde peut travailler de concert et décider à chaque fois de la manière dont l'utilisateur obtient une valeur ajoutée particulièrement élevée. 

Des solutions créatives : Créer des histoires d'utilisateurs dans le développement logiciel Agile Résultats créatifs. Car : ils poussent les équipes à réfléchir de manière critique à la meilleure solution pour le produit final.

Des succès constants : Chaque User Story est un petit défi. Les équipes peuvent donc célébrer un petit succès après chaque story. Cela motive tout au long du processus de développement.

 

Conclusion

Les User Stories sont un outil important dans le travail des équipes agiles. Elles te montrent toujours en détail pour qui tu développes quoi et pourquoi. Cela t'aide non seulement à créer un produit de haute qualité et adapté au groupe cible, mais aussi à maintenir la motivation de l'équipe tout au long du processus. 

Pour que tu puisses réussir à ce niveau macro du travail agile, ton entreprise doit penser et fonctionner de manière agile dans son ensemble. Pour t'aider, toi et ton organisation, nous avons développé avec des experts renommés Projet Scagile conçu. Cela te montre dans différents webinaires comment aborder correctement une transformation agile. La formation est gratuite. N'hésite pas à y jeter un coup d'œil !

Si tu souhaites des questions un peu plus variées pour tes rétrospectives, consulte notre post sur 32 méthodes rétrospectives fraîches pour les débutants et les professionnels (avec, entre autres, la Mario Kart Retro, la Marathon Retro et la Elon Musk Retro).

L'une des meilleures formats de rétrospective pour développer durablement l'état d'esprit agile des membres de l'équipe est d'ailleurs l'implémentation d'un health check agile. Notre Boîte à outils gratuite Team-Health Check peut t'aider à poser les bonnes questions – clique juste.

Partage cet article dans ton réseau

Tu as besoin de booster ton équipe ? Fais ce qui suit La rétrospective Spotify Health Check!

Première question Health : "😍 Nous aimons aller au travail et nous avons beaucoup de plaisir à travailler ensemble".

Envie d'en savoir plus ? Essaie dès maintenant notre outil rétro.

Articles qui pourraient vous intéresser

Echometer Bulletin d'information

Ne manque pas les mises à jour sur Echometer & reçois de l'inspiration pour travailler de manière agile