Aucune image

User story : la forme c’est important !

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…

Aucune image

User Story Map: un gros Plus pour votre Backlog

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).

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.
es 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

Aucune image

User Story vs Use case : soyez Agile !

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 …)..Cette question du choix entre les deux formalismes est récurrente parmi les équipes, et notamment côté Client (Métier ou Maîtrise d’ouvrage), même si je considère pour ma part que les User Stories sont plus appropriées dans la plupart des contextes, notamment Agiles.
Dans les deux cas, un vrai boulot d’accompagnement s’avère bien souvent nécessaire pour favoriser une bonne appropriation et une bonne utilisation sur la quotidien des projets…

Aucune image

Epic et User Stories

Une User story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur. Les User Stories émergent au cours d’ateliers de travail menés avec le Métier, le Client ou les Utilisateurs.

Quelques Exemples :
« En tant que recruteur, je peux déposer des offres d’emploi »; « En tant qu’utilisateur, je peux réserver une chambre d’hôtel »;  » En tant utilisateur, je peux annuler une réservation »; « En tant que jeune diplômé, je peux créer un CV »; « En tant que jeune diplômé je peux supprimer un CV »; « En tant que jeune diplômé je peux modifier un CV »…