Posté par jc-Qualitystreet le 5 mars 2013
L’atelier « User Story Mapping » (inventé par Jeff Patton) devient désormais un grand classique de mes activités de coaching agile auprès des Product Owner. Une activité que j’apprécie tout particulièrement puisque c’est mettre, à moindre coût, quelques éléments de réflexion UX dans une belle dynamique Agile… un grand pas vers l’AgileUX!
Résultat d'un Atelier StoryMap avec un Product Owner motivé
L’activité est à la fois ludique et très efficace ; elle permet très rapidement de donner vie au produit dans une représentation différente, (multidimensionnelle et plus riche) de celle offerte par le Backlog de produit… Lire la suite
Posté par jc-Qualitystreet le 9 février 2012
L’art de la spécification dans un contexte Agile et notamment SCRUM est avant tout une affaire de collaboration, une affaire de comportement. Les User Stories sont un format (que j’apprécie beaucoup) qui permet d’engager la conversation mais qui ne se suffit pas à lui-même… (voir le PROTOTYPAGE AGILE)
Bref, l’idée derrière cette checklist (reprise de Lisa Crispin et Janet Gregory) est de faciliter le boulot du Product Owner en lui rappelant les éléments nécessaires que ses User Stories arrivent Prêtes (ce fameux Ready) en début de sprint.
User Story CheckList
Cette checklist doit être envisagée comme un guide de conversation et non comme un énième format de spécification ! Elle permet aussi d’identifier les éléments complémentaires nécessaires à la réalisation et au test de la story (ex : Wireframe ; Diagramme d’activité…) et fait le lien avec une démarche ATDD.
La partie haute et les premiers éléments sont initiés par le Business; le reste se construit dans un mode « Juste à temps - Juste ce qu’il faut » de manière collaborative avec l’Equipe.
Rappelez- vous Feedback et Collaboration...
Quelques lectures pour approfondir le sujet User Stories:
Posté par jc-Qualitystreet le 24 mars 2011
Une User story est une exigence du système à développer, une brève description d’une fonctionnalité telle que vue par l’utilisateur ; très en vogue sur les projets agiles. Dalleurs je n’utilise quasiment plus que ça.
« En tant que Client, je veux réserver un billet de train pour me rendre à Paris »
Quand on pense aux User Stories, on pense d’abord à la règle des 3C et aux critères de qualité (INVEST) et au format « User Voice”…
User Story INVESTed... dans un format orienté But Utilisateur tourné vers la valeur
Chaque user story sera estimée et priorisée mais ce qui caractérise aussi une user story, c’est qu’elle doit être SUFFISAMMENT PETITE pour être livrée dans un sprint (généralement les équipes embarquent au minimum 3 stories par sprint) . Une véritable nécessité si on veut observer de vrais gains en termes de valeur produite, de visibilité, d’avancement, de flexibilité, de feedback et d’amélioration continue.
Au cours de mes missions de coaching agile, je suis donc régulièrement amené à aider l’Equipe et le Product Owner à décomposer des user stories en user stories plus petites.
Voilà les 10 stratégies de décomposition que je propose, toutes efficaces et éprouvées !
1 Par étapes d’un Workflow
L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémental.
2 Par scenario
On obtient une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’autres pour les cas d’erreurs ou les scénarios alternatifs :quand il se passe x ; quand il se passe y
3 Par séquence dans un scénario
Le cas est plus précis, on découpe cette fois-ci une séquence au sein d’un scénario…
4 Par opérations
Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer.
5 Par format ou type de données
Assez évident aussi. On joue sur le type d’objet (ex : compte titres, espèces… messages en français, anglais, espagnol…)
6 Par type d’entrée, sortie ou configuration
Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi au niveau de l’interface…
7 Par Persona ou rôle
Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’appuyer le user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit.
8 Par niveau de connaissance
Le niveau de connaissance acquis sur une fonctionnalité est un bon critère de décomposition…Une story pour ce qui est connu, une autre là où c’est moins maîtrisé. Çela peut déboucher sur un spike (une user story un peu particulière orientée exploration)
9 Par niveau de complexité
Une user story va par rexemple décrire une fonctionnalité dans son mode de réalisation le plus simple, d’autres suivront par un niveau de complexité plus grand
10 Par niveau de qualité attendu
Performance, Sécurité, Utilisabilité… ces exigences non fonctionnelles constituent le plus souvent des conditions de satisfaction pour des user stories spécifiques mais elles peuvent permettent également de distinguer des user stories entre elles (ex : afficher en moins de 60 sec, moins de 30 sec ; données en temps réels ou non…)
Les illustrations viendront au fur et à mesure ; si vous voulez participer, n’hésitez pas à proposer votre exemple en commentaires avec le n° de stratégie correspondant… un post incrémental et participatif en quelque sorte
Commentaires:
Classé sous: Agile
Posté par jc-Qualitystreet le 9 novembre 2009
Les « User Stories » sont de plus en plus utilisées sur les projets Agiles, et c’est une très bonne chose.
Leur simplicité, leur orientation à la fois « But Utilisateur » et « Valeur Business », ainsi que le focus immédiat sur les critères d’acceptation les rendent en effet terriblement efficaces pour les projets de conception.
Une fois la règle des 3 C assimilée (Carte, Conversation et Confirmation) et les critères INVEST bien décrits, quand les équipes et le Product Owner commencent à découvrir les stories, ils me demandent souvent si le format « User Voice » doit être respecté …
Ce format c’est le fameux :
En tant que < Rôle d’utilisateur >,
Je peux < But >,
Si bien que < Justification >
Un format au sein duquel,
- Le rôle représente celui qui fait l’action et qui en bénéficie
- Le but représente l’action accomplie
- La valeur Business représente les bénéfices qui se dégagent de l’action
Alors, doit-on utiliser ce format ? Ma réponse est sans équivoque OUI !
- Le format “User Voice” donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer
- Il permet de se rapprocher d’une démarche expérience utilisateur, et notamment Personas. Le rôle c’est notre Persona, une vision concrète, réaliste et partagée de l’utilisateur final.
- Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace)
- Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
Mon conseil : Donnez un titre à la User Story (court et signifiant), et décrivez là ensuite au format « User Voice » !
Posté par jc-Qualitystreet le 11 août 2009
Le Story Map est l’un des éléments forts que j’ai retenus de ma dernière certification Product Owner, délivrée par Arlen Bankston (LithtSpeed). C’était en 2009.
MàJ (2013) : Depuis quelques années, l’exercice “User Story Mapping” est un incontournable du coaching de Product Owner
Jeff Patton - Story Map - http://agileproductdesign.com
Intégré à un large radiateur d’informations, le User Story map est une dose supplémentaire d’UX (user Experience) dans votre projet Scrum, le complément idéal, voire indispensable de votre Backlog de produit.
Contrairement au Backlog de produit, le Story Map est multidimensionnel, plus visuel et plus collaboratif notamment au moment de sa construction.
Les règles sont simples:
- Le User Story map représente donc le backlog de produit
- Il est lié aux Personas, placés sur la gauche du Story Map
- Il se lit sur 2 axes:
- Horizontal, l’axe temporel - séquences d’action, que les ergonomes et les analystes apprécieront puisqu’il se fonde sur les analyses de l’activité et analyses métier
- Vertical, l’axe priorité, qui servira à définir quelles User Stories seront retenues sur la release ou sur le sprint
- Les grandes activités sont placée au dessus sur une ligne horizontale (les post it jaunes sur la photo qui suit), puis sont décomposées en User Stories (les post it bleus).
- Les User Stories sont affichées en colonne sous l’activité dont elles dépendent et classées par priorité. La User Story la plus nécessaire à la réalisation de son Activité est placée le plus haut, les autres suivront par ordre d’importance (on peut se réfèrer au modèle de Kano pour le déterminer). Une décomposition trés fine et le respect des critères INVEST pour les User Stories est plus que souhaitable
Jeff Patton - Story Map - http://agileproductdesign.com
Avec le Story Map, vous avez :
- Des user Stories enfin liées les unes aux autres (c’était une vraie lacune de la technique des User Stories jusqu’alors)
- L’association de toute une séquence d’actions et d’un Persona
- Un point d’entrée évident vers d’autres livrables Ux, type Storyboards…
- Une représentation concrète des flux et des séquences dans une approche très orientée Utilisateurs
- Une véritable aide à la priorisation qui met l’accent sur les fonctionnalités nécessaires à la réalisation d’une activité
Bref, un Backlog de produit plus performant, un découpage des sprint et des release plus aisé, et une meilleure appropriation des backlogs (souvent indigestes) par les équipes.
Le User Story Map fait enfin VIVRE le Backlog aux yeux de tous!
Posté par jc-QualityStreet le 16 février 2009
User Stories et Use Cases (cas d’utilisation) sont deux façons très populaires de capturer les besoins utilisateurs (exigences fonctionnelles).
Toutes deux sont orientées BUT, plutôt centrées Utilisateurs, sont découvertes au cours d’ateliers de travail et peuvent être admirablement combinées avec les activités Expérience Utilisateur (Personas, Storyboard, Wireframe …).. Lire la suite
