Les User stories sont des constructions simples, mais extrêmement puissantes: elles décrivent des éléments de fonctionnalité du point de vue d’un utilisateur, exprimés de manière solide et compacte. Ils reflètent ce dont une classe particulière d’utilisateurs a besoin et la valeur à gagner. Le format est très simple et facile à utiliser. Il existe plusieurs variantes, notamment:
Pourquoi les User Stories?
Les User stories offrent un excellent moyen de définir votre produit avec clarté., Un ensemble d’histoires d’utilisateurs bien définies et hiérarchisées peut vous aider à articuler les fonctionnalités de votre produit en « anglais simple » — sans détails techniques et de mise en œuvre.
L’approche « user story » permet des discussions significatives sur les produits, à la fois au sein de l’équipe de développement de produits et avec les parties prenantes externes.
Des histoires d’utilisateurs correctement écrites fournissent une base solide pour la communication et la collaboration — en se concentrant sur ce qui compte le plus pour l’utilisateur., Par rapport à d’autres moyens de capturer et de documenter les besoins des utilisateurs et les spécifications des produits, ils présentent au moins les avantages suivants:
- Les User stories aident à obtenir une clarté inter-équipe sur ce qu’il faut construire, pour qui, pourquoi et quand. Comme ils sont faciles à définir, à comprendre et à réviser, ils peuvent devenir le moyen standard de communiquer et de résumer la fonctionnalité du produit par les membres techniques et non techniques. Ils sont extrêmement utiles pour les discussions sur la portée du produit ou comme points d’entrée pour les plongées techniques. Ce sont des éléments clés de l’ingénierie agile.,
- Les User stories encouragent la participation des membres non techniques. Les projets logiciels modernes sont généralement complexes, impliquant un large éventail de technologies, d’acronymes et d’options de mise en œuvre. Dans de nombreux cas, la terminologie ou le langage technique n’est pas couramment compris — même au sein d’une seule équipe — introduisant ainsi du « bruit » et des risques pour le projet. Les User stories suppriment cette dimension technique, de sorte que tout membre de l’équipe peut contribuer, simplement en pensant « en tant qu’utilisateur »., L’équipe peut utiliser un langage non technique et collaborer efficacement pour définir, contester ou hiérarchiser les histoires d’utilisateurs. L’impact sur la collaboration et la dynamique d’équipe peut être significatif.
- Ils aident à définir l’ensemble du produit — comme un ensemble d’histoires solides et judicieusement hiérarchisées. L’équipe de développement produit peut voir grand, définir le super-ensemble d’user stories, puis attribuer des priorités (qui reflètent la valeur attendue pour l’utilisateur, la complexité, les dépendances et d’autres priorités métier). Vous n’avez pas à prendre de décisions difficiles et à signaler les éléments comme « hors de portée »., Au lieu de cela, vous pouvez attribuer une priorité inférieure à ces idées « folles », tout en augmentant les histoires d’utilisateurs reflétant les fonctionnalités de base de votre produit. La définition des « lignes de coupe » qui déterminent la portée de chaque itération, phase ou version, dépend alors des ressources disponibles et de la vélocité de l’équipe.
Écrire de superbes histoires d’utilisateurs
Le format est simple, et écrire des histoires est facile. Mais écrire de grands pourrait être un peu délicat. Voici quelques lignes directrices à prendre en compte:
articles de l’Utilisateur ≠ tâches
l’Utilisateur histoires ne sont pas des tâches., En fait, une seule histoire peut nécessiter des centaines de tâches uniques pour être livrée avec succès. Les tâches concernent la mise en œuvre; les user stories concernent la définition.
Lorsque vous compilez vos histoires, concentrez — vous sur la clarté des caractéristiques de votre produit-le quoi, pas le comment.
Restez de haut niveau
Vous devez être de haut niveau, mais aussi précis et précis. Les histoires doivent être simples et solides. Cela aidera les membres de l’équipe et les parties prenantes à comprendre en profondeur les besoins des utilisateurs et à éviter de passer du temps à clarifier les mots à la mode, la terminologie et les acronymes. Il suffit d’utiliser un langage simple et précis.,
Comprendre les utilisateurs
Vous devez découvrir et étudier les utilisateurs réels de votre produit — capturer leurs profils, leurs points de vue, leurs attentes et les points de douleur associés. »La recherche d’utilisateurs et d’autres techniques peuvent générer des informations pour vous aider à mieux comprendre les utilisateurs et leurs besoins.
Peu importe les techniques, vous avez besoin de l’ensemble des utilisateurs clés — idéalement sous la forme de personas — avant de commencer à compiler des user stories.,
Penser en tant qu’utilisateur
Le <comme une classe particulière de l’utilisateur/ persona /rôle:> partie d’un article de l’utilisateur, définit l’angle, le point de vue — comment le particulier utilisateur perçoit la fonctionnalité résumées dans l’histoire.
Ceci est d’une importance cruciale — le product owner et toute l’équipe doivent penser du point de vue de l’utilisateur et comprendre les besoins sous-jacents et la valeur attendue.,
Think big
Lorsque vous décrivez un produit comme un arriéré d’histoires d’utilisateurs, il n’y a aucune bonne raison de limiter votre réflexion par le budget, le temps, la faisabilité ou le coût.
Une bonne pratique consiste à voir grand et à laisser les histoires d’utilisateurs « folles » entrer dans le carnet de commandes. Les frais administratifs liés au maintien d’un arriéré de produits étendu sont faibles; la valeur qui en découle — en termes de clarté du produit, de vision et d’opportunités — est énorme.,
Utiliser epics
Epics peut prendre la forme d’histoires de niveau supérieur, qui décrivent de grandes fonctionnalités-elles nécessitent généralement une quantité importante de travail, sur plusieurs sprints. Une autre façon de penser aux épopées est comme des regroupements/ conteneurs d’histoires connexes, plus petites, toutes servant un objectif commun. Les épopées sont bonnes pour organiser vos histoires et fournir une vue d’ensemble.,
Ne pas jeter — prioriser à la place
Compte tenu d’un processus de priorisation efficace, il est recommandé de continuer à enrichir votre carnet de commandes de produits avec de nouvelles histoires d’utilisateurs, décrivant de nouveaux scénarios d’interaction utilisateur, des « idées aléatoires » ou le résultat des activités d’innovation produit.
Pour gérer le bruit potentiel, vous devez regrouper et hiérarchiser correctement les nouvelles entrées. Dans tous les cas, ne filtrez pas/ne défaussez pas les éléments de votre backlog: les éléments de portée sont généralement oubliés, tandis que les éléments de priorité restent détectables et peuvent devenir pertinents dans les bonnes conditions.,
Selon le contexte, hiérarchiser les histoires d’utilisateurs peut être un processus délicat. Vous devez estimer la valeur de chaque histoire, pour l’utilisateur et pour l’entreprise. Vous devez dimensionner la complexité, estimer la faisabilité et le coût/effort requis pour créer et publier la fonctionnalité. Vous devez identifier les dépendances croisées dans votre backlog — en appliquant un ordre spécifique entre certaines entrées.
le programme d’Installation pour le succès — et pas seulement l’acceptation
les Équipes définissent souvent l’utilisateur tests d’acceptation et liées à des critères d’acceptation. L’acceptation ne suffit pas-vous devez vous mettre en place pour réussir., En tant que chef de produit, vous avez besoin de plus qu’une confirmation qu’il fonctionne comme il se doit » ou » selon les spécifications.’
Vous avez besoin de métriques qui sont également liées aux commentaires directs des utilisateurs, capturant à quel point vos utilisateurs réels sont heureux et engagés. Bien que l’acceptation soit bonne pour contrôler le cycle de vie du développement de la fonctionnalité, le succès concerne l’impact à moyen/long terme et la valeur créée pour les utilisateurs réels de votre produit. Vous devez définir les deux-au niveau du produit et / ou de l’épopée et / ou de l’histoire.
la Balise histoires, ajouter des métadonnées
les produits Complexes nécessitent des centaines d’articles de l’utilisateur., Pour faciliter la navigation et l’administration, vous devez nommer, catégoriser et étiqueter efficacement vos histoires. Après les premières révisions d’une histoire, vous devriez éviter de renommer ou de changer radicalement sa description car cela pourrait introduire de la confusion et des lacunes dans l’équipe.
Gérer correctement les métadonnées de vos histoires—statut, progression, liens, priorités, ressources, etc. – aide à explorer, surveiller et comprendre votre arriéré.
Ne vous en tenez pas aux notes autocollantes!,
Oui, un mur plein de notes autocollantes colorées a l’air chic et aide votre équipe à paraître occupée et productive 🙂 Mais vous avez besoin d’un système sérieux et d’outils spéciaux pour vous aider à gérer, enrichir, hiérarchiser et partager des histoires correctement.,
Dans des cas particuliers, comme un remue-méninges ou d’idéation session, c’est bon pour la capture de la première série d’articles de l’utilisateur par l’utilisation de notes autocollantes—à condition que vous puis document tous dans un bon système de gestion des produits. Si vous ne le faites pas et que vous gardez simplement vos histoires sur des notes autocollantes, il y a de fortes chances que vous manquiez des opportunités en termes de clarté, d’innovation, d’efficacité et de collaboration.,
Vous avez toujours besoin de spécifications
Avoir un ensemble hiérarchisé d’histoires utilisateur bien définies est génial, mais ce n’est que le début. L’équipe doit analyser les histoires — d’un point de vue technique — et créer les artefacts techniques nécessaires.
Idéalement, les histoires sont mappées à une documentation spécifique qui fournit tous les détails techniques nécessaires du point de vue de l’ingénierie logicielle. Ils fournissent les points d’entrée pour les documents de spécifications techniques détaillées et d’autres artefacts détaillés.,
Aide à la visualisation
Une visualisation (numérique) permanente des histoires d’utilisateurs prioritaires par catégorie, thème ou epic pourrait être extrêmement utile pour la collaboration et l’alignement entre les équipes et les parties prenantes. Avec les statistiques, les problèmes, les bloqueurs et les indicateurs de progression, une story map peut être diffusée via des écrans interactifs dans l’espace de collaboration.
l’Utilisateur histoires fournissent un excellent moyen de rapidement et avec précision décrire les fonctionnalités d’un produit logiciel ou d’un système., Ils sont également très efficaces pour capturer les résultats des sessions de brainstorming, des sprints de conception, des hackathons et d’autres processus axés sur l’innovation-où un flux d’idées doit être capturé de manière compacte et structurée.