Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019

1
© http://www.oeildecoach.com
C1 - Public Natixis
1
Bonnes pratiques à l’usage des équipes agiles
Rédiger de bonnes
User Stories

2
C1 - Public Natixis

Les origines….

3
C1 - Public Natixis

Un peu d’Histoire…
Dinosaures Préhistoire
2001
JC
0
Moyen Age
& Cycle en V
Matrice rôle-fonctionnalité
de Rachel Davies &
Tim McKinnon en 2001
2001
Les « 3C »
Ron Jeffries
Extreme programming
2006
Matrice given-when-then
décrivant les tests de recette
par Dan North
2003
Grille INVEST
par Bill Wake
"INVEST in Good Stories
and SMART tasks"
Modernité & agilité
JCVD
2004
* JCVD = Comprendre le dernier bon film de Jean-Claude VAN DAMME (humour geek)

4
C1 - Public Natixis

Avec l’arrivée de l’agilité
Finalement, c’est comme avant :
– Recueil des besoins
– Recherche d’idées innovantes
– Groupes de réflexion + ateliers de travail
Mais,
– On ne cherche plus à tout définir à l’avance
– On commence par ce qui a le plus de valeur
– On se concentre sur le point de vue de l’utilisateur
– On affine le besoin directement avec les développeurs et les testeurs

5
C1 - Public Natixis

Les débuts des User Stories
… C’EST L’HISTOIRE
D’UN MEC …

6
C1 - Public Natixis

Les 3 C de Ron JEFFRIES
Ron JEFFRIES
Carte
• Les Story sont traditionnellement écrite sur des cartes
• Les cartes peuvent être annotées avec des estimations,
des commentaires, des règles fonctionnelles, des
critères d’acceptation, etc.
Conversation
Les détails derrières les cartes peuvent être étudiés durant
les conversations avec le Product Owner
Confirmation
La validation des tests confirme que les stories ont été
développées correctement

7
C1 - Public Natixis

Kézako une User Story ?
«
»
Une User Story (US) est le juste
formalisme d’un élément fonctionnel
du point de vue de l’utilisateur,
précisant la valeur apportée à ce dernier.

8
C1 - Public Natixis

Caractéristique d’une User Story
• Compréhensible par tous (pas de terme technique)
• Raconte une histoire liée à un ou plusieurs utilisateurs
• Légère et simple à rédiger (pas de blabla)
• Suffisamment claire pour permettre aux développeurs
d’estimer sa faisabilité
• Réalisable entièrement durant un sprint

9
C1 - Public Natixis

La base

10
C1 - Public Natixis

Formalisation d’une User Story
• Narrative
En tant que <utilisateur>, je veux <verbe d’action>
afin de <bénéfice attendu>.
• Notes
Le contexte, les règles de gestion, les maquettes graphiques, les cas nominaux,
non passant et aux limites, la documentation à disposition, les contraintes
techniques, la sécurité attendue, etc.
• Critères d’acceptation « Gherkin »
 Lorsque <contexte>, quand je <verbe d’action> alors je <résultat attendu>.
Pensez au
jeu de données !

11
C1 - Public Natixis

Exemple d’User Story - Formalisme Gherkin (BDD)
• Narrative
En tant que nouvel utilisateur, je veux créer un compte avec un mot de
passe sécurisé afin de me connecter à mon compte et le message
« Hello <identifiant> » s’affiche.
• Notes
Les mots de passe ne doivent pas être trop courts, ils doivent pouvoir
contenir des caractères spéciaux et des chiffres.
• Critères d’acceptation « Gherkin »
 Lorsque je suis un nouvel utilisateur souhaitant créer un compte,
quand je saisis et valide l’un des mots de passe suivant : p@ssword,
azerty$$, planète!75, Mot_De_Passe!
alors j’arrive sur la page d’accueil de connexion et le message
« Hello <identifiant> » s’affiche.
Lorsque ‘contexte initial’
quand ‘un événement’
alors ‘résultat attendu’
Pensez au
jeu de données !

12
C1 - Public Natixis


13
C1 - Public Natixis

INVEST-issez dans de bonnes User-Stories !
I Indépendante
des stories suivantes (et si possible des
précédentes)
N Négociable avec les développeurs (pour optimiser le ROI)
V Valorisant pour l’utilisateur
E Estimable
pouvant être chiffré, solution technique
connue
S Suffisamment petit
pour éviter l’effet tunnel et tenir en un sprint
(grand max)
T Testable pouvant être testé (sans contrainte)
Bill WAKE

14
C1 - Public Natixis

Comment couper les fonctionnalités ?
En tranches
Pour valider rapidement !
Qui ne peuvent être testées qu’en fin !
Pas en
couches

15
C1 - Public Natixis

Quelques idées pour découper ses User Stories
• Par étapes d’un processus
• Par scénario
• Par étapes d’un scénario
• Par type de données
• Par type d’entrée / sortie
• Par utilisateurs / rôles
• Par niveau de connaissance
• Par complexité
• Par niveau de qualité attendu
• …
Source : http://www.qualitystreet.fr/2017/02/13/user-story-lessentiel-en-5-images/

16
C1 - Public Natixis

Quel niveau de détails pour mes User Stories ?
Une bonne
User Story est
à ce niveau de
détail !
Cloud level – Trop abstrait - niveau Expression de Besoin
Kite Level – Objectifs à long terme, sans aucune
fin précise. Plusieurs opérations fonctionnelles
Clam Level – Trop détaillé
Fish Level – Un élément qui ne veut pas dire
grand-chose unitairement.
Sea Level – Je peux raisonnablement espérer
réaliser cela en un seul sprint.

17
C1 - Public Natixis

SPRINT : Cycle de vie d’une user story
Idée / Besoin
Conversation
Développements + tests
durant le sprint
Incrément
du logiciel
Définit par le métier et/ou le
Product Owner et saisie dans
le product backlog
Echange entre le PO et
l’équipe technique pour affiner
les détails de l’US, avant le
sprint
Réalisation et tests
+ validation par le PO,
pendant le sprint
Livraison des US
« done » en fin de sprint
1
2
3
4

18
C1 - Public Natixis

Le rôle du Product Owner sur une US
Utilisateurs
/ acteurs métiers
Equipe de réalisation
Identifier / recueillir le
besoin (la narrative)
Analyser et prioriser
le besoin
Proposer une
réponse au
besoin Formaliser le besoin
via une user story
Présenter la
user story à l’équipe
de réalisation pour
estimation
Revoir la priorité et
planifier la réalisation
dans un sprint
Suivre la
réalisation de
l’user story
Tester l‘user
story livrée
Présenter l’user story
aux utilisateurs
pour obtenir du feedback
Communication !
PO

19
C1 - Public Natixis

Backlog du produit

20
C1 - Public Natixis

Identifier les US au plus tôt MAIS les préciser au plus tard
Sprint
1 à 3 semaines
24
heures
Sprint
1 à 3 semaines
24
heures
Priorisé
Backlog produit
Sprint
1 à 3 semaines
24
heures
Sprint #0Cadrage Agile
Initialisation
 Sprint Backlog
Sprint #1
Sprint #1
Préparation
 Sprint Backlog
Sprint #2
Sprint #2
Préparation
 Sprint Backlog
Sprint #3
Sprint #3
Préparation
 Sprint Backlog
Sprint #4
Début projet
 Vision
 Personas
 Backlog
 Roadmap
Product
Owner
US prêtes & INVEST US à préciser US identifiées

21
C1 - Public Natixis

Create Sub-Task, inside of 1 Story
Board view
Issue view
Une User Story dans JIRA - exemple

22
C1 - Public Natixis


23
C1 - Public Natixis

«
»
Le meilleur format d’une user story est
celui qui fonctionne avec votre équipe !
N’oubliez pas !

24
C1 - Public Natixis

N’oubliez pas !
• Gardez en tête qu’une User Story est avant tout une histoire qui se raconte !
Elle amène la discussion et aide l’équipe (fonctionnels, développeurs et testeurs)
à confirmer sa compréhension du besoin.
• N’hésitez pas à abuser des dessins, maquettes graphiques, schémas, etc.
 Une image vaut mille mots !
• Ne soyez pas dogmatique, écrivez les user stories dont l’équipe a besoin pour
développer et tester : ni plus, ni moins !
• Demandez régulièrement à l’équipe ce qui peut être amélioré !
Les développeurs et les testeurs sont vos alliés ! 

25
C1 - Public Natixis
ANNEXES

26
C1 - Public Natixis

Pour aller plus loin…
• Patterns for Splitting User Stories
http://agileforall.com/patterns-for-splitting-user-stories/
• Pourquoi découper vos besoins en petites user stories ?
http://blog.Xebia.Fr/2015/12/22/pourquoi-decouper-vos-besoins-en-
petites-user-stories/
• 3 manières de découper ses user stories
https://blog.goood.pro/2014/09/15/3-manieres-de-decouper-ses-user-
stories/
• Agilité: 10 stratégies pour avoir des User Stories suffisamment petites
http://www.qualitystreet.fr/2011/03/24/agilite-10-strategies-pour-des-
user-stories-suffisamment-petites/
• Découper ses user stories
https://fr.linkedin.com/pulse/d%C3%A9couper-ses-user-stories-
christ%C3%A8le-rousseau
• Outils recommandés par Lucy pour les PO
http://lucyinthescrum.com/toolbox/

27
C1 - Public Natixis

Differences between stories, use cases and requirements
Stories Use Cases Requirements
Goal
generate
conversation
capture a behavior establish a contract
Scope a single activity
a process "day in the
life"
everything
Format a single sentence numbered bullets specifications
Completeness
open for negotiation and
refinements
locked, changes may
impact entire process
locked, require scope
change and approvals
Language simple, comprehensible structured, flows precise, technical

28
C1 - Public Natixis

Quels types de tickets sont possibles
VISIBLE PAR
LE CLIENT
VISIBLE PAR
L’EQUIPE
RECUPERE DE LA
VALEUR PERDUE
AJOUTE DE
LA VALEUR
User
Story
Bug
Refacto
Tech
Story

29
C1 - Public Natixis

Ce document est sous licence Creative Commons :
Attribution + Pas d’Utilisation Commerciale (BY NC) : le titulaire des droits autorise
l’exploitation de l’œuvre, ainsi que la création d’œuvres dérivées, à condition qu’il ne
s’agisse pas d’une utilisation commerciale (les utilisations commerciales restant
soumises à son autorisation).
Si vous souhaitez utiliser ce document à des fins commerciales, merci de contacter :
Martial SEGURA – martial.segura [at] oeildecoach.com
Conditions d’utilisation
http://www.oeildecoach.com/

Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019

Similar to Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019 (20)

Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019