Comment découper un besoin pour une réalisation en agile

1. Agile Grenoble 2015
Du Story Mapping
L’art du maniement
des exigences agiles
Alexandre Boutin
Du Story Mapping
aux User Story

2. Alexandre
BOUTIN
Conférencier
Co-Auteur
Fédéré
« Touiteur »
BOUTIN
Formateur / Coach’Agile
« Touiteur »
Blogueur
www.agiletoyou.com
www.agilex.fr
@agilex
Associatif

3. Voici un produit
Voici des itérations

4. Comment faire ?
Quelques idées

5. Résultat obtenu
Ce que l’on voudrait
Faire grossir le produit
Comme une goutte d’eau

6. Comment faire ?

7. Objectifs du Story Mapping
– Rendre visible le flux de production
de valeur
– Montrer les relations entre les
fonctionnalités principales et leur
décompositiondécomposition
– Aider à vérifier la complétude du
besoin fonctionnel
– Fournir un support simple à la
priorisation
– Permettre de s’assurer de la
cohérence des Releases planifiées
Crédit photo : Alexandre Boutin
Bénéfices connexes

8. Construire un Story Mapping
• Décrire comment chaque utilisateur va utiliser le
produit au fil du temps
– Classer les usages de gauche à droite, dans l’ordre qui
vous vient à l’esprit lorsque quelqu’un vous demandevous vient à l’esprit lorsque quelqu’un vous demande
« Que fait cette personne avec votre produit ?»
« Que fait-elle ensuite ? »
Temps
• Décomposer les usages
• Garder la cohérence en vertical
Construire un Story Mapping
Temps

9. L’approche Story Mapping
Quelles sont toutes les choses que vous avez fait
aujourd’hui pour être présent dans cette salle ?
– Commencez au moment de votre réveil
– Finissez à maintenant
17
Quelques exemples
Crédit photos : Alexandre Boutin

10. Trucs et astuces
• Ne pas être trop strict sur l’organisation temporelle
• Alterner entre la discussion sur les usages et leur
décomposition
• Créer une nouvelle colonne s’il y a beaucoup d’éléments
dans la décomposition
• Ecrire lisiblement ☺
• Ne pas hésiter à réécrire un postIt et à jeter le précédent
Le Story Mapping se pratique avec les
utilisateurs
Crédit photo : Alexandre Boutin
Le Story Mapping concentre les énergies et génère des
discussions riches sur le produit

11. Vérifier la complétude
• Chaque type d’utilisateur doit pouvoir « sortir » du Story
Mapping avec de la valeur produite
Crédit photo : Jeff Patton « User Story Mapping »
What-About ?
Game
Un Story Mapping prend de la place
• Pour un projet raisonnablement complexe, il faut
souvent plusieurs murs
Crédit photo : Alexandre Boutin Crédit photo : Alexandre Boutin

12. • Ajouter un axe supplémentaire
Temps
Prioriser avec le Story Mapping
+
Nécessité
-
• Faire glisser les fiches vers le bas et définir des versions
Temps
Prioriser avec le Story Mapping
Nécessité
V1V2+

13. Prioriser par les bénéfices
Les produits à usage interne génèrent des économies financières
Les bénéfices sont la raisons d’être du produit. Ils
sont identifiés en regardant comment travaillent les
utilisateurs, en imaginant d’autres façons de le faire
ou en créant un nouvel usage.
Les produits à usage interne génèrent des économies financières
ou aident à améliorer les services supports aux utilisateurs.
Les produits à usage externe génèrent des revenus financiers,
augmente la fidélisation ou l’engagement des utilisateurs
Les bénéfices du produit sont spécifiques à ce produit et à
chaque utilisateur. Un objectif générique comme “gagner plus
d’argent” n’est pas exploitable.
Le modèle de valeur du produit, utilisé pour la priorisation, est
basé sur ces bénéfices spécifiques.
Quelques exemples
Crédit photo : Alexandre Boutin

14. Trucs et astuces
• Faire bouger plus de la moitié des PostIt
• Rassurer les utilisateurs et stakeholders
• Préciser que ce qui est descendu sera fait … mais plus tard
• Préciser que moins il y a de choses dans la V1 et plus vite le• Préciser que moins il y a de choses dans la V1 et plus vite le
produit sera mis en production
• Faire monter les PostIt
• Adopter une approche minimaliste
• MVS : Minimum Viable Solution (qui peut être validée)
Pour aller plus loin
Jeff Patton

15. Quel rapport avec notre problème ?
Bénéfices du Story Mapping
• Le découpage est réalisé de façon cohérente avec les
participants
• Les éléments identifiés sont indépendants (ou presque)• Les éléments identifiés sont indépendants (ou presque)
• Les éléments de plus haute priorité sont identifiées
• Le sous ensemble identifié (MVP) est complet et offre de la
valeur aux utilisateurs

16. Du Story Mapping aux User Story
Elément du Story
Mapping
User Story 1
User Story 2
User Story 3

17. Une User Story est à usage multiple
Une User Story c’est :
– Un besoin utilisateur
– Une description du Produit
Kent Beck utilise le terme
user story dans son livre
“Extreme Programming
Explained“1er Edition, 1999
– Un élément de planification
– Un support à l’échange
– Un mécanisme pour
retarder la conversation
Une User Story est un outil pour faciliter la
conversation entre différentes personnes
Utilisateur
Comment décrire ce
que j’attends
vraiment ?
Comment puis-je
comprendre les
utilisateurs et leurs
besoins ?
Ergonome
Quels détails de
cette fonctionnalité
dois-je expliciter ?
Quels sont les
éléments qui feront
de mon produit un
succès commercial Utilisateur Ergonome
Business Analyst
Sur quels éléments
dois-je travailler
aujourd’hui ?
Développeur
Comment puis-je
vérifier que le
produit satisfait
l’utilisateur ?
Testeur
Comment savoir la
valeur que
produisent mes
équipes ? Manager
succès commercial
?
Marketing

18. Les « 3C » de Ron Jeffries
C
C
C
C
C
Carte
Conversation
C
Conversation
ConfirmationExtrait de “Extreme
Programing Installed” de
Ron Jeffries
Une Story commence simplement
Commencer avec un titre
Ajouter une description succincte en
Carte
Ajouter une description succincte en
utilisant ce format très pratique :
En tant que [type d’utilisateur]
Je veux [faire quelque chose]
Pour [atteindre un but spécifique]
Ajouter des choses utiles comme des
notes, des règles de gestion, ou des
visuels

19. Partager les User Story
Seul dans son bureau, le
Product Owner rédige toutes
les User Story nécessaires au
projetprojet
La conversation est un
élément fondamental de
l’écriture des User Story
Claude Aubry : « Scrum : le guide pratique de la méthode agile la plus populaire » Edition 4
Une Story évolue avec le temps
Utilisateurs Experts
Conversation
EquipiersSponsors

20. Une Story se termine
Confirmation
Voici ce que nous pensons
vous montrer lorsque nous
aurons fini d’implémenterEquipiers
• Plusieurs techniques
– Critères d’acceptation
– Tests d’acceptation
aurons fini d’implémenter
cette Story, êtes-vous
d’accord ?
Equipiers
Exemple de Critères d’acceptation
• Le pied de l’arbre est enterré
• Un engrais naturel est déposé au fond du trou
• La terre est tassée après la plantation
• La plantation est abondamment arrosée

21. Critères d’acceptation à éviter
• Le trou fait 60 cm de diamètre et 80 cm de profondeur
• L’arbre est planté droit
• La pelouse est tondue autour de l’arbre
• Le panier pour récolter les fruits est acheté
Une User Story est orientée utilisateur
• La mise à disposition d’une User Story impacte
l’utilisateur
• Raisonner « Valeur pour l’utilisateur » et non
« Moyen de le faire »« Moyen de le faire »
Qu’est ce qui est important : Le moyen de faire le trou ou l’arbre ?

22. 2 erreurs classiques
Confondre Livrable et Résultat
Points gagnés ≠ Valeur utilisateur
Conformité objective
User Story ≠ Contrat
Story
fonctionn
elle
Correction
de bug
Les types de story
Visible des stakeholders
Definition
Story
technique
Rembt de
dette
technique
Ajoute de
la valeur
Rétablit
la valeur
Visible des équipiers
Definition
of Done

23. Quel rapport avec notre problème ?
Bénéfices des User Story
• Elles apportent de la valeur aux utilisateurs
• L’effort pour s’accorder sur une Story est
raisonnable (conversation)raisonnable (conversation)
• Elles sont indépendantes fonctionnellement
• Elles sont petites et peuvent être terminées
en 1 itération

24. Soyez sensible à l’altitude *
“Kite level”
Objectifs à long terme, souvent sans aucune fin précise.
Je vais effectuer plusieurs opérations fonctionnelles
dans mon contexte professionnel
Trop abstraite
Pensez feedback
utilisateur à ce
* Extrait de “Writing Effective
Use Cases” d’Alistair Cockburn
“Sea level”
Je peux raisonnablement espérer réaliser cela en 1 seule
opération fonctionnelle
“Fish level”
Un élément qui ne veut pas dire grand-chose unitairement.
J’en ferais plusieurs pour réaliser une opération fonctionnelle
Trop détaillée
utilisateur à ce
niveau

25. Un peu de concret
Fruits naturels
En tant que jardinier du dimanche
Je veux manger des fruits naturels
Pour me faire du bien
Fruits de mon jardin
En tant que jardinier du dimanche
Je veux récolter les fruits de mon jardin
Pour les manger
Planter un arbre fruitier
En tant que jardinier du dimanchePour les mangerEn tant que jardinier du dimanche
Je veux planter un arbre fruitier
Pour récolter des fruits prochainement
Creuser un trou
En tant que jardinier du dimanche
Je veux creuser un trou
Pour planter un arbre
Avoir une pelle
En tant que jardinier du dimanche
Je veux une pelle à bout carré
Pour creuser un trou de 80 cm
Faire petit pour aller vite
et prendre tôt du
feedback
« Size Matters »
Planter un arbre fruitier
En tant que jardinier du dimanche
Je veux planter un arbre fruitier
Pour récolter des fruits prochainement

26. Bien découper une User Story
User Story
Trop Grosse
User Story 1
Couche 1
User Story 3
User Story 2Couche 2
Couche 3
User Story 1
(Orientée Utilisateur)
Etapes pour découper une Story
INVESTEVALUER
DECOUPERSPIKE

27. Techniques de découpage

28. S’entrainer à l’écriture de User Story
Du Story Mapping
L’art du maniement
des exigences agiles
Alexandre Boutin
Du Story Mapping
aux User Story