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.

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.

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)

Ce n’est que la valeur ajoutée qui montre pourquoi une fonction est importante pour l’utilisateur. Le POURQUOI vous permet donc de réfléchir honnêtement à la qualité de votre connaissance des exigences d’un client. Car : Il est facile d’intégrer une exigence dans une User Story, par exemple parce que le client exprime ce souhait. Mais ce n’est que lorsque vous comprenez pourquoi le client en a besoin que vous disposez du contexte nécessaire à la mise en œuvre de l’exigence. Ce n’est qu’alors que vous pouvez vous demander si la proposition/le souhait du client satisfait efficacement son besoin réel - ou s’il existe éventuellement une manière plus intelligente. 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 vous ne devez pas nécessairement fournir un poncho de pluie. Vous pourriez aussi fournir un vélo avec un toit intégré. L’essentiel est que le besoin ou le problème du client soit résolu, à savoir ne pas être mouillé. Mieux vous comprenez le « pourquoi », mieux vous pouvez concevoir votre User Story.

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. 

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. 

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 : Écrire des User Stories peut parfois prendre beaucoup de temps, mais elles ne doivent pas pour autant être gravées dans le marbre. 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.

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.

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 méthodes pour développer durablement l’état d’esprit agile des membres de l’équipe est d’ailleurs la mise en place d’un bilan de santé agile. Notre Boîte à outils gratuite Team-Health Check peut vous aider à poser les bonnes questions - cliquez et parcourez.