Les développeurs de logiciels ont régulièrement besoin de commentaires sur leurs produits et il n'y a pas de meilleure source que de les obtenir directement des utilisateurs finaux. Pour obtenir ces informations vitales, vous avez besoin d'un modèle de user story. Avec cela, vous pouvez rédiger des user stories contenant des informations essentielles sur cette histoire qui vous aideront en fin de compte à améliorer le produit ou le service.
Modèles de user stories
#01
#02
#03
#04
#05
#06
#07
#08
#09
#dix
Qu'est-ce qu'un modèle de user story ?
Un modèle de user story est la plus petite unité de travail dans un cadre agile. Il s'agit d'un objectif final, pas d'une fonctionnalité que vous exprimez de votre point de vue en tant qu'utilisateur de logiciel . Un exemple de user story est généralement de nature informelle et fournit une explication générale d’une fonctionnalité logicielle spécifique.
L'un des principaux objectifs d'un modèle de user story agile est d'expliquer comment un emploi offre une certaine valeur à son client. Ici, les « clients » ne sont pas toujours des utilisateurs finaux externes au sens traditionnel du terme. Ils peuvent également faire référence à des collègues ou des clients internes de votre organisation qui font confiance à votre équipe.
La plupart des user stories consistent généralement en quelques phrases écrites dans un langage simple qui indiquent le résultat souhaité sans entrer dans les détails. Ajoutez des exigences beaucoup plus tard, lorsque les autres membres de l'équipe sont d'accord.
Les user stories peuvent parfaitement s’intégrer dans des frameworks Agile comme Kanban et Scrum. Dans Kanban, les équipes extraient les histoires de backlog et les exécutent ensuite tout au long de leur flux de travail. Dans Scrum, vous ajoutez des histoires aux sprints, puis vous les « enregistrez » pendant toute la durée du sprint.
C'est le travail sur les user stories qui aide les équipes Scrum à améliorer la planification et l'estimation des sprints, ce qui peut conduire à une plus grande agilité et à des prévisions plus précises. Pour les équipes Kanban, les user stories vous permettent de mieux apprendre à gérer les travaux en cours et d'affiner davantage vos workflows.
Ce document sert également de pierre angulaire dans des cadres plus larges tels que les initiatives et les épopées. Les épopées sont des œuvres plus vastes divisées en un ensemble d’histoires. Plusieurs épopées comportent des initiatives. Ces structures plus grandes garantissent que le travail quotidien de votre équipe contribue à vos objectifs organisationnels globaux.
Formats de user story
#onze
#12
#13
#14
#quinze
#seize
#17
#18
#19
#vingt
Pourquoi avez-vous besoin de user stories ?
Si vous avez déjà travaillé avec des frameworks agiles, vous devez déjà savoir que les équipes Kanban et Scrum bénéficient grandement de la rédaction d'exemples de user stories. Dans Kanban, votre équipe accumule des histoires dans un backlog puis les exécute une par une pour prendre en charge le workflow en cours. Cela vous aide à rester sur la bonne voie tout en améliorant les KPI de votre équipe de développement.
Si vous faites partie d'une équipe Scrum, vous pouvez utiliser activement le modèle de user story pour établir des priorités, puis planifier des sprints et estimer pour rester flexible et agile en cas de changements. Cela devient plus avantageux lorsque vous travaillez avec des startups où vous disposez de ressources limitées avant de présenter le projet aux investisseurs.
Voici les autres avantages de l’utilisation d’un format user story :
- Cela vous permet de rester concentré sur la valeur de votre entreprise. Cela contribue à rendre votre création non seulement efficace d’un point de vue technique, mais également très utile pour les utilisateurs finaux.
- Cela vous permet d’être plus créatif. Étant donné que le document contient peu d’informations, votre équipe est libre d’utiliser des idées créatives pour trouver la meilleure solution.
- Votre projet sera plus gérable car il est plus facile de travailler avec des formats de user story petits et estimables au lieu de tâches volumineuses et complexes.
- Ils inspirent également leur équipe, car chaque développeur aime le sentiment de petites victoires, ce qui le motive à travailler plus dur.
Exemples de user stories
#vingt-et-un
#22
#23
#24
#25
#26
#27
#28
#29
#30
Comment rédiger un modèle de user story ?
Idéalement, dans la plupart des organisations agiles, c'est le propriétaire du produit qui assume la responsabilité principale de la rédaction d'un modèle de user story agile, puis de son organisation dans le backlog produit. Mais dans le monde réel, la création du modèle de user story est une responsabilité partagée entre les membres de l’équipe. Voici les étapes pour créer votre propre format de user story :
- Déterminez à quoi cela ressemblera une fois « terminé ».
La plupart du temps, la user story explique l'état final. C'est à ce moment-là que l'utilisateur peut atteindre l'objectif ou terminer la tâche décrite. Gardez cet état final à l'esprit lorsque vous rédigez votre user story afin que le reste de votre équipe sache quand il peut marquer votre travail de développement comme « terminé ». - Documentez toutes les sous-tâches et tâches
. Votre user story doit non seulement inclure l'instruction standard, mais également documenter les détails nécessaires pour effectuer le travail de développement dans la story. Cela implique de décrire les sous-tâches et les tâches, puis de les attribuer aux bonnes personnes. - Déterminez les personnalités des utilisateurs.
Qui comptez-vous servir dans votre histoire ? À quel type de client ou d’utilisateur pensez-vous ? Vous devez immédiatement documenter les réponses à ces questions. Si vous avez de nombreux utilisateurs différents en tête, vous devriez envisager de les diviser en plusieurs user stories. Cela permet à votre équipe de rester concentrée sur l’aide à une personne spécifique pour atteindre un objectif spécifique pour chacune de ses histoires. - Créez des histoires sous forme de petites étapes ordonnées
Le concept de user story suggère que vous pouvez considérer l'ensemble de votre produit comme une série de tâches ou de tâches que le produit aide ses utilisateurs à accomplir. Si vous essayez de formater le travail en un processus à plus grande échelle ou un ensemble plus détaillé de fonctionnalités de produit, vous pouvez écrire chacune des étapes indépendantes sous forme d'histoires individuelles. - Demandez les commentaires des utilisateurs
Vous pouvez améliorer vos chances d'allouer des ressources à des travaux de développement qui correspondent à votre marché en discutant avec les clients et les utilisateurs de leurs priorités, puis en apprenant ce qu'ils veulent d'autre. Vous ne devriez commencer à créer vos user stories qu’après avoir collecté puis analysé ces commentaires. - Brouillons d'histoires que vous pouvez réaliser en un seul sprint
Les user stories qui dépassent un sprint doivent être décomposées en histoires plus courtes. Cela donne à votre équipe un sentiment d'achèvement après chaque sprint, car elle peut compléter de nouvelles fonctionnalités à chaque fois. De plus, cela vous permet également de publier plus fréquemment de nouvelles fonctionnalités sur le marché.
Exemples de récits d'utilisateurs
#31
#32
#33
# 3. 4
#35
#36
#37
#38
#39
Comment rédiger une user story en Agile ?
Il existe de nombreuses opinions différentes sur la manière dont un modèle de user story doit être défini et sur la meilleure façon d’en créer un. Voici quelques conseils pour rédiger de bons exemples de user stories :
- Il doit provenir d'une personne qui représente les utilisateurs professionnels.
- Au départ, vous devez inclure de brèves descriptions du « quoi, pourquoi et qui », mais pas du « comment ».
- Vous devez créer un code fonctionnel sous la forme d'une tranche verticale.
- Il doit être suffisamment petit pour que vous puissiez le coder et le tester en une seule itération.
Il existe plusieurs techniques, acronymes et modèles que vous pouvez obtenir lors de la rédaction de modèles de user story Word. Les plus courantes de ces techniques sont :
- Rôle-Fonctionnalité-Raison
Il existe plusieurs variantes de l'exemple de user story lors de l'utilisation de cette méthode, mais le fait d'avoir une structure de phrases courtes permet de se concentrer sur quoi, pourquoi et qui. Cela vous évite de donner trop de détails à votre équipe de développement sur la manière dont elle doit mettre en œuvre la solution. En se concentrant sur quoi, pourquoi et qui, votre équipe se sentira habilitée à trouver la meilleure solution. - Les Trois C (Carte, Conversation, Confirmation)
Vous pouvez utiliser la méthode des Trois C pour parvenir à un accord entre votre entreprise et votre équipe technique sur la signification de votre user story. Votre équipe peut utiliser les Trois C comme guide pour développer progressivement l’histoire, d’une brève déclaration à une histoire entièrement développée. - INVESTIR
C'est l'acronyme d'une user story forte. Il vous aide à évaluer si vous disposez ou non d’une user story de haute qualité. Pour mieux comprendre cela, il faut connaître la signification de chaque lettre de cet acronyme :
I pour Indépendant
Votre équipe terminera-t-elle l'histoire ? Il est préférable que votre équipe termine l'histoire plutôt que de s'appuyer sur une autre équipe pour réaliser une interface graphique, par exemple.
N pour Négociable
L'histoire ne doit pas être trop détaillée en décrivant la longueur des champs ou en fournissant des détails sur les formats de date et d'autres informations. Il y a de fortes chances qu'il existe des bibliothèques ou des routines communes qui permettent à votre équipe de développement d'utiliser une méthode qui lui semble logique.
V pour Valuable
En tant que Product Owner, vous décrirez la valeur recherchée comme la capacité d'un formateur à annoncer les cours à venir. Vous devez expliquer cela clairement dans le « pourquoi » de la déclaration originale, puis le souligner à nouveau lorsque vous avez des conversations.
E pour Estimable
Vous devez confier à votre équipe la tâche de poser des questions, puis de recueillir des informations pour avoir suffisamment confiance dans sa capacité à estimer l'histoire.
S pour Small
Votre équipe doit être sûre qu'elle terminera l'histoire en un sprint. S’ils ne le peuvent pas, ils devraient envisager de diviser l’histoire en parties plus petites.Prenons, par exemple, un exemple d'histoire dans laquelle vous développez une application qui permet aux formateurs de télécharger du matériel pédagogique qui attire les étudiants intéressés à suivre un cours. Votre équipe peut choisir de faire de la possibilité de collecter des informations sur les élèves une histoire distincte en affichant des informations sur la classe pour cette histoire.
T pour Testable
Avec des critères d'acceptation clairs, vous pouvez tester à la fois les conditions d'erreur et le chemin heureux.
Modèles associés