Modèles gratuits de récits d’utilisateurs
Les modèles suivants peuvent être utilisés à des fins diverses. Vous pouvez rédiger, cartographier et gérer le backlog des récits d’utilisateurs, écrire des épopées, etc. Beaucoup de ces modèles sont similaires, alors choisissez en fonction de vos préférences personnelles ou du processus spécifique de votre entreprise (et donc du format).
Les chefs de produit et de projet peuvent utiliser le modèle de backlog pour suivre les récits d’utilisateurs, tandis qu'ils peuvent se servir d'autres modèles pour créer ou cartographier des récits d’utilisateurs. Les autres membres de l’équipe peuvent avoir recours aux modèles de récits d’utilisateurs ou d'épopées pour créer des récits d’utilisateurs.
Modèle de récit d’utilisateur
Les récits d’utilisateurs aident les équipes de produits à rester concentrées sur les besoins des utilisateurs et à gérer leur travail lors du développement de fonctionnalités. Les chefs de projet et de produit peuvent utiliser ce modèle pour gérer le travail généré par les utilisateurs. Tous les autres membres de l’équipe peuvent s'en servir pour rédiger des récits d’utilisateurs.
Modèle de backlog de récit d’utilisateur
Utilisez ce modèle pour gérer votre backlog de récits d’utilisateurs lors des itérations de développement de produits.
Le backlog est créé lors de la planification du sprint, lorsqu’une équipe sélectionne les éléments prioritaires du backlog produit et les ajoute à ses sprints. Le backlog comprend tous les travaux passés en phase de développement et constitue une liste de tâches à accomplir dans l’itération en cours. Cette liste doit être définitive (c'est-à-dire que des tâches ne doivent plus être ajoutées ou supprimées à ce stade).
Le modèle contient des colonnes pour les éléments de backlog, les points de récit, les responsabilités, le statut et les estimations initiales. Dans les colonnes représentant les jours 1 à 5, les chefs de produit ou de projet peuvent ajouter le nombre d’heures de développement supplémentaires requises chaque jour pour une tâche. Le nombre total d’heures de développement supplémentaires pour chaque jour pour toutes les tâches du sprint apparaît dans la ligne Total. Le graphique d'avancement représente alors ce travail exceptionnel.
Modèle de cartographie de récit d’utilisateur
Il s’agit d’un modèle que vous pouvez compléter ou recréer à l’aide de notes adhésives ou de fiches. Le nombre de cases peut varier en fonction des activités qui se déroulent lors de l’utilisation d’un système donné.
Les chefs de projet et de produit peuvent utiliser ce modèle pour ordonner les activités auxquelles les utilisateurs sont confrontés quand ils utilisent un système. L’axe des ordonnées représente la sophistication croissante des fonctionnalités qui sont cartographiées ; l’axe des abscisses correspond à l’ordre séquentiel des activités auxquelles les utilisateurs sont confrontés quand ils utilisent un système. La première ligne contient les fonctionnalités les plus basiques et les lignes suivantes deviennent plus complexes.
Télécharger le modèle sous Excel
Modèle d'épopée
Une épopée est une partie du travail qui traite certaines des fonctionnalités à développer, qui peuvent être utilisées pour générer des récits d’utilisateurs. Utilisez ce modèle pour rédiger des épopées. Ensuite, retracez les récits d’utilisateurs générés à partir de chaque épopée. Les chefs de projet et de produit peuvent utiliser ce modèle pour gérer le travail généré par les épopées, et tous les autres membres de l’équipe peuvent s'en servir pour créer des épopées.
Télécharger le modèle d'épopée concernant des récits d'utilisateurs agiles - Excel
Qu’est-ce qu’un récit d’utilisateur ?
Un récit d’utilisateur est une description courte (une phrase ou deux), simple et spécifique d’une interaction avec un produit en cours de développement, généralement une application ou un site Web. (Ces récits peuvent bien sûr également être utilisés pour le développement d’autres projets.) Les récits d’utilisateurs servent de cadre pour guider les développeurs, les concepteurs, les chefs de produit et d’autres parties prenantes dans la création d’un produit.
Les récits d’utilisateurs doivent définir les utilisateurs et ce que ces derniers feront avec le produit ou le service. Ils doivent également contenir un type d’utilisateur, l’action souhaitée de la part de cet utilisateur et la valeur qu’en tirera l'utilisateur lorsque l’action sera terminée. Toutefois, un récit d’utilisateur ne doit pas décrire comment mettre en œuvre ou développer une caractéristique ou une fonction.
Les récits d’utilisateurs font partie intégrante de la méthodologie Agile de développement logiciel. Par rapport aux méthodes traditionnelles de gestion de projet (c'est-à-dire en cascade), la méthode Agile est un processus flexible et itératif. La méthode Agile fonctionne par cycles, appelés itérations, qui durent d'une à quatre semaines. Dans le cadre de chaque itération, les développeurs cherchent à créer de nouvelles fonctionnalités ou à améliorer les fonctionnalités existantes. Les récits d'utilisateurs sont utilisés pour guider la création de fonctionnalités. Les modèles téléchargeables gratuitement ci-dessous peuvent être utilisés pour créer et travailler avec des récits d’utilisateurs lors de différentes phases du processus Agile. Pour en savoir plus sur la méthode Agile et télécharger gratuitement des modèles de gestion de projet agile, cliquez ici.
Qu’est-ce que la méthode Scrum ?
Scrum est une variante de la méthode Agile largement utilisée. Il existe quelques différences entre les pratiques des deux méthodes : Scrum fait référence à une réunion d’équipe brève et quotidienne pour discuter de l’avancement et des plans. Dans la méthode Scrum, les cycles sont dénommés sprints au lieu d’itérations et les critères d’acceptation sont appelés définition de fini (DoD). Cependant, les méthodes Scrum et Agile présentent des principes directeurs communs.
Quelle est la structure d’un récit d’utilisateur ?
En l'absence d'un format spécifique pour les récits d’utilisateurs de la méthode Agile, il existe un certain nombre de variations (présentant simplement de légères variations de terminologie). La forme de base d’un récit d’utilisateur adopte le point de vue d’un utilisateur donné du produit et décrit ce que celui-ci veut faire avec le produit et la valeur qu'il tirera de cette fonctionnalité : En tant que , je veux
- En tant que opérateur/trice de saisie de données, je veux télécharger des feuilles de calcul, afin d'éviter d'avoir à couper et coller des données.
- En tant que représentant(e) commercial(e) itinérant(e), je veux importer les photos des tickets de caisse, afin de ne plus avoir à les transporter.
- En tant que responsable financier/ière, je veux pouvoir apporter des modifications aux modèles de notes de frais, afin d'éviter d'avoir à manipuler les notes de frais tous les mois.
Comment les récits d’utilisateurs sont-ils créés ?
Les récits d’utilisateurs sont souvent tirés d’épopées, qui suivent généralement un format similaire à celui des récits. Cependant, les épopées sont de plus haut niveau et couvrent plusieurs fonctions. (Elles peuvent aussi être énoncées sous forme de phrases courtes.) Les épopées étant trop vastes pour être terminées dans une seule itération de la méthode Agile, elles doivent être décomposées. L’idée n’est pas d’éliminer quoi que ce soit de l’épopée, mais de créer des récits d’utilisateurs suffisamment granulaires pour être terminés en une seule itération. Voici des exemples d’épopées pour une application de calendrier :
- En tant qu’utilisateur/trice, je veux gérer tous mes rendez-vous depuis mon téléphone.
- En tant qu’utilisateur/trice, je veux voir en même temps mon planning familial et mon planning professionnel.
- En tant qu’utilisateur/trice, je veux disposer de toutes les fonctionnalités du rappel sans ouvrir l’application.
Au début, il peut être difficile de faire la distinction entre une épopée et un récit d’utilisateur, mais cela devient plus facile avec l’expérience.
Les épopées et les récits d’utilisateurs doivent être fondés sur les besoins des utilisateurs plutôt que sur des spéculations : les entretiens avec des utilisateurs ou des utilisateurs potentiels garantissent des récits ancrés dans la réalité.
De nombreuses entreprises utilisent également des personas lorsqu'elles créent des récits d’utilisateurs. Un persona est une courte biographie d’un utilisateur fictif qui aide les concepteurs et les développeurs à se concentrer sur un type d’utilisateur spécifique plutôt que sur un utilisateur imaginaire général.
Certaines sociétés décomposent les récits d’utilisateurs en récits enfants (également appelés sous-récits), qui permettent d'adapter le travail requis à une seule itération. Cependant, certaines personnes estiment que si un récit d’utilisateur peut être décomposé ou ne correspond pas à une itération, il s'agit en fait d'une épopée.
Qui rédige des récits d’utilisateurs ?
Toute personne travaillant sur un projet peut rédiger des récits d’utilisateurs à tout moment pendant le projet. Généralement, une session d’écriture de récits se déroule avant la première itération, ce qui donne à l’équipe produit un backlog de récits à traiter. Pour en savoir plus sur le processus de rédaction des récits d’utilisateurs, cliquez ici.
Il existe des cadres utiles pour vous aider à rédiger de bons récits d’utilisateurs. L’un des cadres les plus connus est un mnémonique appelé INVEST, créé par le consultant et développeur Bill Wake :
- Indépendant : il doit être autonome (c'est-à-dire ne pas dépendre d’un autre récit d’utilisateur).
- Négociable : il doit laisser de la marge de manœuvre.
- Valorisable : le récit doit apporter de la valeur aux parties prenantes.
- Estimable : les efforts nécessaires à la mise en œuvre de la fonctionnalité du récit doivent pouvoir être estimés.
- Suffisamment petit : il doit pouvoir être terminé en un seul sprint.
- Testable : le récit doit inclure suffisamment de détails pour permettre la création de tests qui vérifient la fonctionnalité concernée par le récit.
Quels sont les avantages des récits d’utilisateurs ?
Les récits d’utilisateurs sont devenus populaires dans les méthodologies Agile ou autres, car ils apportent de la valeur et aident les équipes de développement de produits à travailler à la réalisation de l'objectif de création de fonctionnalités qui répondent aux besoins des utilisateurs. Voici quelques-uns des avantages des récits d’utilisateurs :
- Il s'agit d'un moyen simple de voir quelles nouvelles fonctions et caractéristiques sont nécessaires.
- Ils clarifient les fonctionnalités requises pour résoudre les problèmes des clients.
- Ils sont faciles à comprendre et à mémoriser.
- Ils se concentrent sur la valeur commerciale et les besoins des clients.
- Ils facilitent la hiérarchisation des priorités.
- Ils se focalisent sur la façon dont les clients potentiels utiliseront le produit.
- Ils permettent de gagner du temps, car il y a moins de faux départs.
- Ils peuvent être utilisés pour retracer l’historique du produit en suivant les fonctionnalités ajoutées à chaque itération.
- Ils mettent l'accent sur la discussion des exigences plutôt que leur rédaction.
- Ils peuvent présenter différents niveaux de détail.
- En décomposant le travail en petits morceaux, ils offrent de la souplesse en termes de mise en œuvre.
- Les spécifications techniques sont laissées aux développeurs.
- Ils favorisent la collaboration et les solutions créatives.
- Ils améliorent le retour sur investissement et le moral de l’équipe.
Quels sont les défis des récits d’utilisateurs ?
Bien que les récits d’utilisateurs soient utiles, comme tout processus ou outil commercial, ils ne sont pas parfaits. Voici quelques-uns des défis associés :
- Ils n'abordent pas les parcours des utilisateurs, la conception visuelle ou les exigences techniques.
- La clause finale des récits d’utilisateurs est souvent négligée par les rédacteurs, alors qu'il s'agit de la partie la plus importante du processus.
- Si les rédacteurs ne disposent pas des bonnes données ou ne plongent pas dans les données qu’ils possèdent afin d’en extraire les besoins des utilisateurs, les récits d’utilisateurs seront insuffisants.
- Le fait de ne pas comprendre pleinement les utilisateurs conduira à des récits qui ne répondent pas à leurs besoins réels.
- Si les équipes de produits ne disposent pas de l’expertise requise, les récits d’utilisateurs ne répondront pas efficacement aux besoins des utilisateurs.
Comment les récits d’utilisateurs sont-ils mis en œuvre ?
Les récits d’utilisateurs constituent le point de départ d'une discussion d’équipe. Cette discussion doit générer plus de détails et des idées spécifiques sur la façon d’implémenter la fonction décrite, afin qu’elle soit utile pour l’utilisateur. Si vous avez créé des personas, il est utile de les utiliser au cours de ces discussions pour maintenir l'approche centrée sur l’utilisateur.
Pendant la discussion, les récits d’utilisateurs peuvent être affichés sur un canevas de produit, avec les personas, les épopées et d’autres éléments connexes, à l’aide d’un outil tel que StoriesOnBoard ou FeatureMap. Certaines équipes créent également des maquettes à faible résolution pour permettre ensuite de passer en revue les fonctionnalités qui fourniront une solution au problème abordé par le récit d’utilisateur.
Une fois que les récits d’utilisateurs ont été créés et discutés, ils doivent être cartographiés. La cartographie est un processus qui consiste à établir une grille de récits d’utilisateurs dans des groupes logiques liés à une caractéristique, à une fonction ou à des tâches que les utilisateurs accomplissent. Chaque groupe est appelé thème. Il existe de nombreuses façons de cartographier les récits d’utilisateurs, notamment en les écrivant sur des notes adhésives et en les collant au mur, ou en utilisant une boîte pleine de fiches et en les étalant sur une table. Pour en savoir plus sur la cartographie des récits d’utilisateurs, cliquez ici.
Comme nous l'avons mentionné précédemment, les récits d’utilisateurs sont rassemblés dans un backlog. Le backlog est une liste hiérarchisée des fonctionnalités qui seront créées pour le produit. Le/la responsable du produit est chargé(e) de s’assurer qu’il existe suffisamment de récits d’utilisateurs dans le backlog pour chaque itération. Même si certaines entreprises utilisent d’autres éléments dans leur backlog, les récits d’utilisateurs constituent l’élément le plus populaire.
Dans la gestion de projet en cascade, un document d’exigences indique les caractéristiques et fonctionnalités qui seront incluses dans le produit final. Bien que les récits d’utilisateurs ne constituent pas de véritables exigences, dans la gestion de projet Agile, le backlog a une finalité similaire à celle du document d’exigences.
En raison de sa structure, un backlog dans la méthode Agile est beaucoup plus fluide que celui d’un document d’exigences de la méthode en cascade. Les récits du backlog doivent être dotés d'identifiants uniques pour faciliter la traçabilité depuis l’origine du récit (par exemple, un rapport de bug, des entretiens avec les utilisateurs, un ticket d’assistance ou la suggestion d’un développeur) et tout au long de son développement, des tests et du lancement. Les outils courants pour suivre les récits jusqu'au lancement comprennent JIRA, GitHub, FogBugz, ou même une feuille de calcul Excel.
Une fois que l'équipe sera d’accord sur les récits initiaux, elle doit se réunir pour étoffer le reste des informations requises pour le développement, les tests et les autres étapes du processus. Elle doit également déterminer les fonctionnalités décrites dans les récits d’utilisateurs qui seront développées en priorité. À nouveau, en raison de la structure de la méthode Agile, la hiérarchisation est fluide et changera en réponse aux nouveaux besoins des utilisateurs, récits d’utilisateurs et pressions concurrentielles.
Comment savoir si vous avez terminé de travailler sur un récit d’utilisateur ?
Pour tout récit, vous avez besoin d’un moyen de vérifier que la fonctionnalité souhaitée a été implémentée avec succès. Quelques expressions sont utilisées pour décrire ce processus, à savoir les critères d’acceptation et les conditions de satisfaction. Certains experts disent que ces deux termes sont synonymes ; d’autres estiment que les conditions de satisfaction sont d'un niveau plus élevé que les critères d’acceptation, et que les détails des critères d’acceptation sont utilisés pour vérifier que les conditions de satisfaction sont remplies.
Qui utilise les récits d’utilisateurs ?
Dans la méthode Agile, l'ensemble de l'équipe peut utiliser des récits d’utilisateurs dans le cadre de son travail sur un projet, mais voici une liste des membres clés de l’équipe :
- Responsables des produits : pour veiller à ce que le produit livré réponde aux besoins des utilisateurs.
- Développeurs : pour guider le travail de l’équipe.
- Testeurs : pour vérifier que le produit fonctionne comme prévu.
- Rédacteurs techniques : pour veiller à ce que tous documents d'accompagnement couvrent les cas d’utilisation importants.
À l’exception des développeurs, chacune de ces personnes peut agir en tant que mandataire du client, en jouant le rôle d’un client ou d’un utilisateur.
Améliorez la rédaction de récits d’utilisateurs grâce à Smartsheet pour le développement logiciel
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.