1 les utilisateurs passent en premier

comme son nom l’indique, une histoire d’utilisateur décrit comment un client ou un utilisateur utilise le produit; elle est racontée du point de vue de l’utilisateur. De plus, les User stories sont particulièrement utiles pour capturer une fonctionnalité spécifique, comme la recherche d’un produit ou la réservation. L’image suivante illustre la relation entre l’utilisateur, l’histoire et la fonctionnalité du produit (symbolisée par le cercle).,

Si vous ne savez pas qui sont les utilisateurs et les clients et pourquoi ils souhaitent utiliser le produit, vous ne devez pas écrire d’histoires utilisateur. Effectuez d’abord les recherches nécessaires sur les utilisateurs, par exemple en observant et en interrogeant les utilisateurs. Sinon, vous prenez le risque d’écrire des histoires spéculatives qui sont basées sur des croyances et des idées—mais pas sur des données et des preuves empiriques.

2 Utilisez Personas pour découvrir les bonnes histoires

Une Excellente technique pour capturer vos idées sur les utilisateurs et les clients travaille avec personas., Les Personas sont des personnages fictifs basés sur une connaissance de première main du groupe cible. Ils se composent généralement d’un nom et d’une image, de caractéristiques, de comportements et d’attitudes pertinents et d’un objectif. Le but est le bénéfice que le personnage veut atteindre, ou le problème que le personnage veut voir résolu en utilisant le produit.

Mais il y a plus: les objectifs de persona vous aident à découvrir les bonnes histoires: demandez-vous quelles fonctionnalités le produit devrait fournir pour atteindre les objectifs des personas, comme je l’explique dans mon post de Personas à User Stories., Vous pouvez télécharger un modèle pratique pour décrire vos personas à partir de romanpichler.com/tools/persona-template.

3 Créer des histoires en collaboration

Les histoires utilisateur sont conçues comme une technique légère qui vous permet de vous déplacer rapidement. Ils ne sont pas une spécification, mais un outil de collaboration. Les histoires ne doivent jamais être transmises à une équipe de développement. Au lieu de cela, ils devraient être intégrés dans une conversation: le propriétaire du produit et l’équipe devraient discuter des histoires ensemble. Cela vous permet de capturer uniquement la quantité minimale d’informations, de réduire les frais généraux et d’accélérer la livraison.,

Vous pouvez aller plus loin dans cette approche et écrire des histoires en collaboration dans le cadre de votre processus de toilettage de l’arriéré de produits. Cela tire parti de la créativité et des connaissances de l’équipe et se traduit par de meilleures histoires d’utilisateurs.

Si vous ne pouvez pas impliquer l’équipe de développement dans le travail de l’histoire utilisateur, vous devriez envisager d’utiliser une autre technique plus formelle pour capturer les fonctionnalités du produit, telles que les cas d’utilisation.

4 Gardez vos histoires simples et concises

écrivez vos histoires pour qu’elles soient faciles à comprendre. Gardez-les simples et concis., Évitez les termes confus et ambigus et utilisez la voix active. Concentrez-vous sur ce qui est important et laissez de côté le reste. Le modèle ci-dessous met l’utilisateur ou le client modélisé en tant que personnage dans l’histoire et rend son avantage explicite. Il est basé sur le modèle populaire de Rachel Davies, mais j’ai remplacé le rôle de l’utilisateur par le nom du personnage pour connecter l’histoire avec le personnage pertinent.

<persona> ,
je veux <quoi?>
alors que <pourquoi?>.,

utilisez le modèle quand il est utile, mais ne vous sentez pas obligé de toujours l’appliquer. Expérimenter les différentes façons d’écrire vos histoires pour comprendre ce qui fonctionne le mieux pour vous et votre équipe.

5 Commencez par des épopées

Une épopée est une grande histoire sommaire et grossière. Il est généralement divisé en plusieurs histoires d’utilisateurs au fil du temps-en tirant parti des commentaires des utilisateurs sur les premiers prototypes et les incréments de produits. Vous pouvez le considérer comme un titre et un espace réservé pour des histoires plus détaillées.

commencer par epics vous permet d’esquisser la fonctionnalité du produit sans vous engager dans les détails., Ceci est particulièrement utile pour décrire les nouveaux produits et fonctionnalités: il vous permet de capturer la portée approximative, et il vous fait gagner du temps pour en savoir plus sur la meilleure façon de répondre aux besoins des utilisateurs.

il réduit également le temps et les efforts nécessaires pour intégrer de nouvelles informations. Si vous avez beaucoup d’histoires détaillées dans le carnet de commandes de produits, il est souvent difficile et fastidieux de relier les commentaires aux éléments appropriés et cela comporte le risque d’introduire des incohérences.,

6 affinez les histoires jusqu’à ce qu’elles soient prêtes

Divisez vos épopées en histoires plus petites et détaillées jusqu’à ce qu’elles soient prêtes: claires, réalisables et testables. Tous les membres de l’équipe de développement doit avoir une compréhension commune de l’histoire du sens; l’histoire ne doit pas être trop grand et s’adapter confortablement dans un sprint; et il y a un moyen efficace pour déterminer si l’histoire est.

7 Ajouter des critères d’acceptation

lorsque vous divisez les épopées en histoires plus petites, n’oubliez pas d’ajouter des critères d’acceptation., Les critères d’acceptation complètent le récit: ils vous permettent de décrire les conditions à remplir pour que l’histoire soit terminée. Les critères enrichissent l’histoire, ils la rendent testable, et ils s’assurent que l’histoire peut être démotivée ou diffusée aux utilisateurs et aux autres parties prenantes. En règle générale, j’aime utiliser trois à cinq critères d’acceptation pour les histoires détaillées.

8 utiliser des cartes papier

Les histoires D’utilisateurs ont émergé dans Extreme Programming (XP), et la littérature des débuts de XP parle de cartes d’histoire plutôt que d’histoires d’utilisateurs., Il y a une raison simple: les User stories ont été capturées sur des cartes papier. Cette approche offre trois avantages: Premièrement, les cartes papier sont bon marché et faciles à utiliser. Deuxièmement, ils facilitent la collaboration: chacun peut prendre une carte et noter une idée. Troisièmement, les cartes peuvent être facilement regroupées sur la table ou le mur pour vérifier la cohérence et l’exhaustivité et pour visualiser les dépendances. Même si vos histoires sont stockées électroniquement, il vaut la peine d’utiliser des cartes papier lorsque vous écrivez de nouvelles histoires.

9 Gardez vos histoires visibles et accessibles

Les histoires veulent communiquer des informations., Par conséquent, ne les cachez pas sur un lecteur réseau, la jungle intranet de l’entreprise ou un outil sous licence. Rendez-les visibles, par exemple, en les posant sur le mur. Cela favorise la collaboration, crée la transparence et le rend évident lorsque vous ajoutez trop d’histoires trop rapidement, car vous commencerez à manquer d’espace mural. Un outil pratique pour découvrir, visualiser et gérer vos histoires est mon canevas de produit illustré ci-dessous.

10 Ne vous fiez pas uniquement aux User Stories

La création d’une expérience utilisateur exceptionnelle (UX) nécessite plus que des user stories., Les User stories sont utiles pour capturer les fonctionnalités du produit, mais elles ne sont pas bien adaptées pour décrire les parcours utilisateur et la conception visuelle. Par conséquent, complétez les histoires d’utilisateurs avec d’autres techniques, telles que des cartes d’histoire, des diagrammes de flux de travail, des storyboards, des croquis et des maquettes.

de plus, les user stories ne permettent pas de saisir les exigences techniques. Si vous avez besoin de communiquer ce qu’un élément architectural comme un composant ou un service devrait faire, écrivez des histoires techniques ou—ce qui est ma préférence—utilisez un langage de modélisation comme UML.,

enfin, écrire des user stories vaut la peine lorsque vous développez un logiciel susceptible d’être réutilisé. Mais si vous souhaitez créer rapidement un prototype ou une maquette jetable pour valider une idée, écrire des histoires peut ne pas être nécessaire. Rappelez—vous: les User stories ne visent pas à documenter les exigences; elles veulent vous permettre de vous déplacer rapidement et de développer des logiciels le plus rapidement possible, sans imposer de frais généraux.