Guide de mêlée | 19. User Stories - qu'est-ce que c'est ?

User Story est une brève description d'une nouvelle fonctionnalité du produit ou de son amélioration. Il 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 but ? La User Story décrit le produit dans un langage courant ou professionnel, bien qu'elle indique également les tâches de l'équipe Scrum destinées à améliorer les performances de l'équipe.

Qu'est-ce qu'une User Story ? - table des matières:

1. Introduction
2. Histoire de l'utilisateur. C'est l'histoire de qui ?
3. Comment utiliser les User Stories ?
4. Critères d'acceptation
5. Sommaire

Introduction

La 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. Il 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 de la durée de travail sur le Produit. Ils sont créés en continu, depuis le moment où la décision de commencer le travail est prise jusqu'à la réalisation de l'Objectif Produit.

La création de User Stories est la tâche d'un Product Owner. Sur la base d'une conversation avec un Client, formule des réponses aux questions qui permettent de créer des User Story et les inscrit dans le Product Backlog. Cependant, les User Stories ne reflètent pas seulement les besoins des clients.

Histoire de l'utilisateur. C'est l'histoire de qui ?

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 en langage métier. En d'autres termes, il indique les avantages que sa mise en œuvre 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 workflow 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 alors contenue dans une formule :

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

Des exemples de User Stories sur la fonctionnalité d'une boutique en ligne écrites 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 un langage technique en business et inversement . En conséquence, les développeurs et les parties prenantes voient clairement l'objectif et les étapes de sa progression. Nous aborderons également la création de bonnes User Stories à l'aide de la méthode INVEST dans un article séparé de la série Scrum Guide.

Comment utiliser les User Stories ?

La création d'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 pendant la planification du sprint pour trier les problèmes techniques que l'équipe de développement ajoutera au backlog du sprint.

Généralement, 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 mieux.

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

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

L'équipe de développement estime l'effort requis pour terminer une User Story avec des jours, des heures de travail ou des 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 le 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 façon, le client et les développeurs savent comment leur travail se traduira en valeur commerciale. En règle générale, une User Story est considérée comme terminée lorsque l'utilisateur qui y est spécifié peut effectuer l'action décrite. En utilisant l'exemple ci-dessus, jetez un œil à cette User Story avec le contenu :

Un client peut acheter une baguette magique en un seul clic.

Il est terminé lorsqu'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é.

Sommaire

Une User Story est une description concise d'une nouvelle fonctionnalité ou amélioration d'un produit. Il sert de plus petit objectif exprimé dans le langage des affaires, c'est-à-dire du point de vue de la valeur commerciale et de l'utilisateur. Il aide à définir clairement la tâche à accomplir ainsi que les critères de sa réalisation.

Si vous aimez notre contenu, rejoignez notre communauté d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit