Guide Scrum | 19. Histoires d’utilisateur – qu’est-ce que c’est ?

La User Story est une brève description d’une nouvelle fonctionnalité du produit ou de son amélioration. Elle ne contient pas de solution technique mais répond à des questions concernant la fonctionnalité : Qui est l’utilisateur ? Que fait le produit ? Et quel est son objectif ? La User Story décrit le produit dans un langage courant ou commercial, bien qu’elle pointe également vers les tâches de l’équipe Scrum qui visent à améliorer la performance de l’équipe.

Qu’est-ce que les User Stories ? – table des matières :

1. Introduction
2. User Story. De qui est l’histoire ?
3. Comment utiliser les User Stories ?
4. Critères d’acceptation
5. Résumé

Introduction

User Story est la manière la plus courante de formuler les tâches effectuées par l’équipe Scrum. Une seule User Story définit une petite fonctionnalité du produit. Elle décrit le plus petit objectif de produit significatif et partiel. Pour cette raison, les User Stories sont très brèves.

Les User Stories sont créées tout au long du travail sur le produit. Elles sont créées en continu, depuis le moment où la décision de commencer le travail est prise, jusqu’à la réalisation de l’objectif du produit.

Créer des User Stories est une tâche du Product Owner. Sur la base d’une conversation avec un client, il formule des réponses aux questions qui permettent de créer une User Story et les entre dans le Product Backlog. Cependant, les User Stories reflètent non seulement les besoins des clients.

User Story. De qui est l’histoire ?

L’équipe Scrum crée une User Story pour définir les besoins de l’utilisateur, et c’est pourquoi elle est rédigée dans un langage commercial. En d’autres termes, elle indique les avantages que son implémentation apportera à l’utilisateur du produit. Cependant, dans le Product Backlog, il peut également y avoir des User Stories qui décrivent les besoins de l’équipe de développement, par exemple améliorer le flux de travail entre les développeurs, ou décrire les besoins du Product Owner, par exemple organiser le Product Backlog. Dans de tels cas, l’utilisateur dans la User Story est le développeur et le Product Owner.

Vous pouvez décrire une User Story en répondant aux questions 3W :

• Qui ?
• Fait Quoi ?
• Pourquoi ?

La User Story est ensuite contenue dans une formule :

En tant que [type d’utilisateur], je veux [faire quoi ?] Parce que [pourquoi ?].

Des exemples de User Stories concernant la fonctionnalité d’une boutique en ligne rédigées sous cette forme sont illustrés dans le tableau ci-dessous :

Cette formule permet non seulement de formuler une User Story mais aussi de traduire relativement facilement le langage technique en langage commercial et vice versa. En conséquence, les développeurs et les parties prenantes voient clairement l’objectif et les étapes de son avancement. Nous aborderons également la création de bonnes User Stories en utilisant la méthode INVEST dans un article séparé de la série Scrum Guide.

Comment utiliser les User Stories ?

Créer une User Story schématique n’est que le début. Ce sont des signaux et des points de départ pour des discussions sur les problèmes et leurs solutions. La discussion des User Stories a lieu lors de la planification du Sprint pour trier les problèmes techniques que l’équipe de développement ajoutera au Sprint Backlog.

Typiquement, dans l’espace physique, les User Stories sont écrites sur de petites cartes colorées épinglées sur le lieu de travail. Cependant, dans l’espace numérique, les tableaux blancs numériques, partagés par l’équipe Scrum, fonctionnent le mieux.

Enregistrer les User Stories de cette manière présente plusieurs avantages car :

• Souligne l’autonomie de chaque User Story – chacune a un cadre séparé et peut être exécutée indépendamment des autres
• Met en avant la dynamique des User Stories – l’ordre de leur réalisation est renégocié par l’équipe Scrum et l’ordre actuel de réalisation est visible sur le tableau grâce à l’agencement physique des cartes avec les User Stories
• Fait office de rappel – grâce à la représentation visuelle des User Stories, l’équipe Scrum a un panneau indicateur en vue pour lui rappeler l’objectif lors de la création de solutions détaillées.

L’équipe de développement estime l’effort nécessaire pour compléter une User Story en jours, heures-homme ou Story Points.

Critères d’acceptation

Une User Story doit avoir certains critères d’acceptation au moment même où elle est acceptée pour développement par l’équipe de développement. Les critères d’acceptation déterminent à quel moment le travail sur une User Story peut être considéré comme terminé.

De cette manière, à la fois le client et les développeurs savent comment leur travail se traduira en valeur commerciale. Typiquement, une User Story est considérée comme terminée lorsque l’utilisateur spécifié peut effectuer l’action décrite. En utilisant l’exemple ci-dessus, regardez cette User Story avec le contenu :

Un client peut acheter une baguette magique d’un simple clic.

Elle est considérée comme terminée lorsque un bouton “Acheter maintenant” fonctionnel apparaît sur la page de la boutique en ligne, qui utilise les informations de paiement et d’expédition par défaut pour l’utilisateur connecté.

Résumé

Une User Story est une description concise d’une nouvelle fonctionnalité ou d’une amélioration du produit. Elle sert de plus petit objectif exprimé dans un langage commercial, c’est-à-dire du point de vue de la valeur commerciale et de l’utilisateur. Elle aide à définir clairement la tâche à accomplir ainsi que les critères de son achèvement.

Si vous aimez notre contenu, rejoignez notre communauté de travailleurs acharnés sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.