SlideShare une entreprise Scribd logo
1  sur  41
1
© http://www.oeildecoach.com
1
ou Comment comprendre et s’améliorer dans la
rédaction des User Stories ?
USER STORIES de A à US
2
© http://www.oeildecoach.com

 Les origines des User Stories
 Définition d’une User Story
 Méthode INVEST
 Erreurs à éviter
 Conclusion
Sommaire
3
© http://www.oeildecoach.com
des User Stories
Les origines
4
© http://www.oeildecoach.com

5
© http://www.oeildecoach.com

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
6
© http://www.oeildecoach.com

Suite à 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
Cependant,
– 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
7
© http://www.oeildecoach.com

Les débuts des User Stories
… C’EST L’HISTOIRE D’UN
MEC …
8
© http://www.oeildecoach.com

Les 3 C de Ron JEFFRIES
Ron JEFFRIES
Carte
• Les Stories sont traditionnellement écrites sur des cartes
• Les cartes peuvent être annotées avec des estimations,
des commentaires, 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 (PO)
Confirmation
La validation des tests confirme que les stories ont été
développées correctement
9
© http://www.oeildecoach.com
des User Stories
La définition
10
© http://www.oeildecoach.com

«
»
Une user story est une invitation à
avoir une conversation avec son client
et l’équipe sur un sujet particulier.
Définition d’une User Story
11
© http://www.oeildecoach.com

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 (format post-it)
 Suffisamment claire pour permettre aux développeurs
d’estimer sa faisabilité
 Réalisable entièrement durant un sprint
12
© http://www.oeildecoach.com

Formalisation d’une User Story
• Narrative
En tant que <utilisateur>, je veux <verbe d’action>
afin de <d’obtenir un bénéfice>.
• Notes
Le contexte, les règles de gestion, les maquettes,
les cas nominaux et les cas aux limites, la documentation à disposition,
les contraintes techniques particulières, etc.
• Critères d’acceptation « Gherkin »
 Lorsque <contexte>, quand <action> alors <résultat attendu>.
 Lorsque <contexte>, quand <action> alors <résultat attendu>.
 Lorsque <contexte>, quand <action> alors <résultat attendu>.
Lorsque ‘contexte initial’
quand ‘un événement’
alors ‘résultat attendu’
13
© http://www.oeildecoach.com

Exemple d’User Story
• 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 un nouvel utilisateur souhaite créer un compte, quand il saisit
l’un des mots de passe suivant : p@ssword, azerty$$, planète!75,
Mot_De_Passe! alors il arrive sur la page d’accueil de connexion et le
message « Hello <identifiant> » s’affiche.
Give <initial context>
When <something happens>
Then <some expectation>
14
© http://www.oeildecoach.com
La méthode INVEST
15
© http://www.oeildecoach.com

16
© http://www.oeildecoach.com

INVEST-issez dans de bonnes User-Stories !
I Indépendant
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 (pas de “afin de” bateau)
E Estimable
(doit pouvoir être chiffré, solution technique
connue)
S Suffisamment petit
pour éviter l’effet tunnel et tenir en un sprint
(grand max)
T Testable (doit pouvoir être testé)
Bill WAKE
17
© http://www.oeildecoach.com
pour rédiger de meilleurs User Stories
Les erreurs à éviter
18
© http://www.oeildecoach.com

FAILS
19
© http://www.oeildecoach.com

Surcharger les post-its ?
Erreur courante #1
La Story
N°ID
Complexité
Qui réalise ?
EPIC
Valeur métier
20
© http://www.oeildecoach.com

Surcharger les post-its ?
Erreur courante #1 > Recommandation

Recherchez constamment la simplicité !
21
© http://www.oeildecoach.com

Transformer un cahier des charges en un backlog
d’User Stories ?
Erreur courante #2
Cahier des charges Backlog
22
© http://www.oeildecoach.com

Transformer un cahier des charges en un backlog
d’User Stories ?
Erreur courante #2 > Recommandation
Organisez des ateliers Vision, Personas, User Story Mapping et
Roadmap avec les parties prenantes pour bien (re)démarrer !

23
© http://www.oeildecoach.com

Une User Story peut servir à un découpage technique ?
Erreur courante #3
24
© http://www.oeildecoach.com

Une User Story peut servir à un découpage technique ?
Erreur courante #3 > Recommandation

Changez la formulation pour raconter une histoire,
les détails pourront être échangés durant la réalisation !
25
© http://www.oeildecoach.com

Préciser tous les détails, dès la création de la User Story
alors que j’en aurai besoin plus tard, dans un sprint futur ?
Erreur courante #4
26
© http://www.oeildecoach.com

Préciser tous les détails, dès la création de la User Story
alors que j’en aurai besoin plus tard, dans un sprint futur ?
Erreur courante #4 > Recommandation

Temps
Précisez les User Stories au plus proche
du sprint concerné par sa réalisation !
27
© http://www.oeildecoach.com

Les User Stories précisent chaque détail d’une page ou d’un
processus ?
Erreur courante #5
28
© http://www.oeildecoach.com

Les User Stories précisent chaque détail d’une page ou d’un
processus ?
Erreur courante #5 > Recommandation
Echangez avec les développeurs pour connaitre le
niveau de détail attendu dans les Users Stories !

29
© http://www.oeildecoach.com

La User Story est beaucoup trop grosse pour entrer dans un
sprint ?
Erreur courante #6
30
© http://www.oeildecoach.com

La User Story est beaucoup trop grosse pour entrer dans un
sprint ?
Erreur courante #6 > Recommandation

Découpez l’Epic en plusieurs User Stories !
31
© http://www.oeildecoach.com

N’avoir que 1 ou 2 User Stories par développeur et par
sprint ?
Erreur courante #9
Création d’un effet tunnel garanti
qui risque de mettre le sprint en péril
32
© http://www.oeildecoach.com

N’avoir que 1 ou 2 User Stories par développeur et par
sprint ?
Erreur courante #9 > Recommandation
Mieux découper les US pour produire plus
de 4 User Stories par développeur / sprint

33
© http://www.oeildecoach.com

Passer à « done », une User Story qui ne devrait pas l’être ?
Erreur courante #10
34
© http://www.oeildecoach.com

Passer à « done », une User Story qui ne devrait pas l’être ?
Erreur courante #10 > Recommandation
1/ Ne pas compter une user story
« not done » dans la vélocité
2/ Reportez la user story et ses
points dans le sprint suivant
3/ Essayez de mieux découper les
stories dans le futur

35
© http://www.oeildecoach.com

Confondre une User Story et un Use Case ?
Erreur courante #11
User Story Use
Case
36
© http://www.oeildecoach.com

Confondre une User Story et un Use Case
Erreur courante #11 > Recommandation

En savoir plus : http://leanmagazine.net/req/a-use-case-is-to-a-user-story-as-a-gazelle-to-a-gazebo/
37
© http://www.oeildecoach.com
En conclusion…
38
© http://www.oeildecoach.com

«
»
Le meilleur format d’une user story est
celui qui fonctionne avec votre équipe !
N’oubliez pas !
39
© http://www.oeildecoach.com

N’oubliez pas !
• Gardez en tête qu’une user story est avant tout une histoire qui se raconte,
crée la discussion et amène l’équipe à confirmer sa compréhension du
besoin.
• N’hésitez pas à abuser des dessins, maquettes, schémas, wireframes, etc.
 Une image vaut mieux que mille mots !
• Ne soyez pas dogmatique, écrivez les user stories dont l’équipe a besoin
pour développer : ni plus, ni moins !
• Demandez régulièrement à l’équipe ce qui peut être amélioré
 Le PO doit aider constamment l’équipe de réalisation
40
© http://www.oeildecoach.com

Sources
• http://fr.slideshare.net/yquenechdu/rdiger-des-user-stories
• http://blog.xebia.fr/2012/06/20/scrum-master-academy-parlons-des-
user-stories/
• http://fr.slideshare.net/yquenechdu/agile-user-story-4482606
• http://www.qualitystreet.fr/2009/02/16/user-story-vs-use-case-soyez-
agile/
• http://leanmagazine.net/req/a-use-case-is-to-a-user-story-as-a-gazelle-
to-a-gazebo/
41
© http://www.oeildecoach.com

Usagecommercialnonautorisé
Usagecommercialnonautorisé

Contenu connexe

Tendances

Corrigé TP NoSQL MongoDB (5).pdf
Corrigé TP NoSQL MongoDB (5).pdfCorrigé TP NoSQL MongoDB (5).pdf
Corrigé TP NoSQL MongoDB (5).pdfOumaimaZiat
 
Formation JPA Avancé / Hibernate gratuite par Ippon 2014
Formation JPA Avancé / Hibernate gratuite par Ippon 2014Formation JPA Avancé / Hibernate gratuite par Ippon 2014
Formation JPA Avancé / Hibernate gratuite par Ippon 2014Ippon
 
L’intelligence artificielle
L’intelligence artificielleL’intelligence artificielle
L’intelligence artificielleiapassmed
 
Réseaux des neurones
Réseaux des neuronesRéseaux des neurones
Réseaux des neuronesMed Zaibi
 
Managers 4 Clés pour Réussir la Gestion des Talents
Managers 4 Clés pour Réussir la Gestion des TalentsManagers 4 Clés pour Réussir la Gestion des Talents
Managers 4 Clés pour Réussir la Gestion des TalentsHR SCOPE
 
Avoir confiance en soi : Atelier EWA Network
Avoir confiance en soi : Atelier EWA Network Avoir confiance en soi : Atelier EWA Network
Avoir confiance en soi : Atelier EWA Network Kriss Brochec
 
Techniques d'ideation – Amelle Ruslier
Techniques d'ideation – Amelle RuslierTechniques d'ideation – Amelle Ruslier
Techniques d'ideation – Amelle RuslierFlupa
 
Comment reussir son pitch ?
Comment reussir son pitch ?Comment reussir son pitch ?
Comment reussir son pitch ?FIDAQUITAINE
 
Programmation orientée objet : Object, classe et encapsulation
Programmation orientée objet : Object, classe et encapsulationProgrammation orientée objet : Object, classe et encapsulation
Programmation orientée objet : Object, classe et encapsulationECAM Brussels Engineering School
 
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)Brigitte Annet
 
522 - La boîte à outils des formateurs (1).pdf
522 - La boîte à outils des formateurs (1).pdf522 - La boîte à outils des formateurs (1).pdf
522 - La boîte à outils des formateurs (1).pdfYoussef795209
 
Négocier avec la PNL - Programmation neuro linguistique
Négocier avec la PNL - Programmation neuro linguistiqueNégocier avec la PNL - Programmation neuro linguistique
Négocier avec la PNL - Programmation neuro linguistiquezouhairjemmaa
 

Tendances (20)

Corrigé TP NoSQL MongoDB (5).pdf
Corrigé TP NoSQL MongoDB (5).pdfCorrigé TP NoSQL MongoDB (5).pdf
Corrigé TP NoSQL MongoDB (5).pdf
 
Charte d'équipe
Charte d'équipeCharte d'équipe
Charte d'équipe
 
Formation JPA Avancé / Hibernate gratuite par Ippon 2014
Formation JPA Avancé / Hibernate gratuite par Ippon 2014Formation JPA Avancé / Hibernate gratuite par Ippon 2014
Formation JPA Avancé / Hibernate gratuite par Ippon 2014
 
L’intelligence artificielle
L’intelligence artificielleL’intelligence artificielle
L’intelligence artificielle
 
Taxonomie bloom aquops2010_final
Taxonomie bloom aquops2010_finalTaxonomie bloom aquops2010_final
Taxonomie bloom aquops2010_final
 
Réseaux des neurones
Réseaux des neuronesRéseaux des neurones
Réseaux des neurones
 
Managers 4 Clés pour Réussir la Gestion des Talents
Managers 4 Clés pour Réussir la Gestion des TalentsManagers 4 Clés pour Réussir la Gestion des Talents
Managers 4 Clés pour Réussir la Gestion des Talents
 
Avoir confiance en soi : Atelier EWA Network
Avoir confiance en soi : Atelier EWA Network Avoir confiance en soi : Atelier EWA Network
Avoir confiance en soi : Atelier EWA Network
 
Techniques d'ideation – Amelle Ruslier
Techniques d'ideation – Amelle RuslierTechniques d'ideation – Amelle Ruslier
Techniques d'ideation – Amelle Ruslier
 
Comment reussir son pitch ?
Comment reussir son pitch ?Comment reussir son pitch ?
Comment reussir son pitch ?
 
Gestion d'équipe
Gestion d'équipeGestion d'équipe
Gestion d'équipe
 
Pitcher une idée
Pitcher une idéePitcher une idée
Pitcher une idée
 
Taxonomie couleur2
Taxonomie couleur2Taxonomie couleur2
Taxonomie couleur2
 
Algorithmes de jeux
Algorithmes de jeuxAlgorithmes de jeux
Algorithmes de jeux
 
Programmation orientée objet : Object, classe et encapsulation
Programmation orientée objet : Object, classe et encapsulationProgrammation orientée objet : Object, classe et encapsulation
Programmation orientée objet : Object, classe et encapsulation
 
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)
Feedback, feedforward et reconnaissance par COHERENCE (intro de formation)
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
522 - La boîte à outils des formateurs (1).pdf
522 - La boîte à outils des formateurs (1).pdf522 - La boîte à outils des formateurs (1).pdf
522 - La boîte à outils des formateurs (1).pdf
 
Négocier avec la PNL - Programmation neuro linguistique
Négocier avec la PNL - Programmation neuro linguistiqueNégocier avec la PNL - Programmation neuro linguistique
Négocier avec la PNL - Programmation neuro linguistique
 
2. leadership
2. leadership2. leadership
2. leadership
 

Similaire à Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com

Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Oeil de Coach
 
Cas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightCas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightArnaud Auroux
 
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolution
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolutionLA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolution
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolutionOCTO Technology
 
Gestion de projet #4 : spécification
Gestion de projet #4 : spécificationGestion de projet #4 : spécification
Gestion de projet #4 : spécificationJean Michel
 
Customer Show case : Mise en place d’une solution de gestion de projet avec l...
Customer Show case : Mise en place d’une solution de gestion de projet avec l...Customer Show case : Mise en place d’une solution de gestion de projet avec l...
Customer Show case : Mise en place d’une solution de gestion de projet avec l...Microsoft Ideas
 
Exemple de mise en place d'une solution EPM 2013
Exemple de mise en place d'une solution EPM 2013Exemple de mise en place d'une solution EPM 2013
Exemple de mise en place d'une solution EPM 2013Charbel Abdo
 
Développer ou debugger ?
Développer ou debugger ? Développer ou debugger ?
Développer ou debugger ? Microsoft
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesOxalide
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceLudovic Piot
 
Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx FranceMarc Bojoly
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache MavenArnaud Héritier
 
10 tips pour améliorer les performances de vos applications Windows 8
10 tips pour améliorer les performances de vos applications Windows 810 tips pour améliorer les performances de vos applications Windows 8
10 tips pour améliorer les performances de vos applications Windows 8Microsoft
 
Uni.sherbrooke 2015 créez la meilleur application grâce à gwt, gwtp et j...
Uni.sherbrooke 2015   créez la meilleur application grâce à gwt, gwtp et j...Uni.sherbrooke 2015   créez la meilleur application grâce à gwt, gwtp et j...
Uni.sherbrooke 2015 créez la meilleur application grâce à gwt, gwtp et j...Arcbees
 
Responsive web design new14
Responsive web design new14Responsive web design new14
Responsive web design new14FullSIX Group
 
Gestion de Forum des Entreprises de L’ Enicarthage
Gestion de Forum des Entreprises de L’ EnicarthageGestion de Forum des Entreprises de L’ Enicarthage
Gestion de Forum des Entreprises de L’ EnicarthageOumaymaLimeme
 
Spring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'tsSpring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'tsJulien Wittouck
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Ippon
 

Similaire à Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com (20)

Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
Mieux rediger-les-user-stories-bonnes-pratiques-oeildecoach 2019
 
Cas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De SilverlightCas Pratique Du Mode DéConnecté De Silverlight
Cas Pratique Du Mode DéConnecté De Silverlight
 
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolution
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolutionLA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolution
LA DUCK CONF 2023 - La vie d'Ops au coeur d'un SI en évolution
 
Gestion de projet #4 : spécification
Gestion de projet #4 : spécificationGestion de projet #4 : spécification
Gestion de projet #4 : spécification
 
Customer Show case : Mise en place d’une solution de gestion de projet avec l...
Customer Show case : Mise en place d’une solution de gestion de projet avec l...Customer Show case : Mise en place d’une solution de gestion de projet avec l...
Customer Show case : Mise en place d’une solution de gestion de projet avec l...
 
Exemple de mise en place d'une solution EPM 2013
Exemple de mise en place d'une solution EPM 2013Exemple de mise en place d'une solution EPM 2013
Exemple de mise en place d'une solution EPM 2013
 
Développer ou debugger ?
Développer ou debugger ? Développer ou debugger ?
Développer ou debugger ?
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slides
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performance
 
cours1-2-vision-bklog.pdf
cours1-2-vision-bklog.pdfcours1-2-vision-bklog.pdf
cours1-2-vision-bklog.pdf
 
Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx France
 
Perf university
Perf universityPerf university
Perf university
 
20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven20081113 - Nantes Jug - Apache Maven
20081113 - Nantes Jug - Apache Maven
 
10 tips pour améliorer les performances de vos applications Windows 8
10 tips pour améliorer les performances de vos applications Windows 810 tips pour améliorer les performances de vos applications Windows 8
10 tips pour améliorer les performances de vos applications Windows 8
 
Uni.sherbrooke 2015 créez la meilleur application grâce à gwt, gwtp et j...
Uni.sherbrooke 2015   créez la meilleur application grâce à gwt, gwtp et j...Uni.sherbrooke 2015   créez la meilleur application grâce à gwt, gwtp et j...
Uni.sherbrooke 2015 créez la meilleur application grâce à gwt, gwtp et j...
 
Responsive web design new14
Responsive web design new14Responsive web design new14
Responsive web design new14
 
SQLI - Club des DSI - Mobilité
SQLI - Club des DSI - MobilitéSQLI - Club des DSI - Mobilité
SQLI - Club des DSI - Mobilité
 
Gestion de Forum des Entreprises de L’ Enicarthage
Gestion de Forum des Entreprises de L’ EnicarthageGestion de Forum des Entreprises de L’ Enicarthage
Gestion de Forum des Entreprises de L’ Enicarthage
 
Spring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'tsSpring Boot & Containers - Do's & Don'ts
Spring Boot & Containers - Do's & Don'ts
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
 

Oeil user story_bonnes_pratiques_Martial_SEGURA oeildecoach.com

Notes de l'éditeur

  1. A l’origine de l’Histoire, il y avait les dinosaures…
  2. Ce n’est pas à proprement parler un élément du framework Scrum, cette pratique nous vient de l’Extreme Programming, mais elle est largement utilisée dans le cadre de projets menés en Scrum au point de devenir la référence de nombreuses formations certifiantes. 3C : CARD + CONVERSATION + CONFIRMATION (ce qui fait que la user story sera done)
  3. Les pratiques Agile sont orientées autour de l’utilisateur final. Il est au centre de la démarche. On raconte notre histoire avec les User Stories. On présente notre histoire avec le résultat : le produit.
  4. Ron Jeffries est un informaticien américain né en 1939 et un des trois fondateurs de l'Extreme programming (XP) créé en 1996, avec Kent Beck et Ward Cunningham. Il est l'un des 17 signataires du Manifeste Agile.
  5. Ce n’est donc ni un besoin, ni une solution, la User Story est une conversation.
  6. La user-story est un formalisme pour décrire une fonctionnalité du point de vue de l’utilisateur. Ca semble très simple, mais le but est justement de réduire la forme à l’essentiel pour se concentrer sur la valeur. La phrase : En tant que = l’utilisateur qui reçoit la valeur (pas nécessairement celui qui fait l’action) « QUI » Je veux = l’action qui doit être menée (~ la solution utilisateur / verbe infinif) « QUOI » Afin de = le but de l’action (~ le besoin utilisateur) « POURQUOI » ID / Titre (verbe infinitif) / Valeur métier / Epic ou Thème / Règles gestion / Wireframe / Pré-requis / Contexte / Complexité tech
  7. Méthode Gherkins : Give <some initial context> When <something happens> Then <some expectation> Le BDD (Behavior Driven Development) est une méthodologie agile proposée par Dan North pour aller au delà du TDD (Test Driven Development). Cette méthodologie a pour objectif d’améliorer la compréhension et la collaboration du métier, du Product Owner, des développeurs, des testeurs et de toute autre partie prenante pertinente en les rassemblant autour d’un langage commun : le Gherkin.
  8. Vous voulez être aussi fort que Hulk ?
  9. I – Indépendante : elle doit se suffire à elle-même, car les dépendances avec d’autres user stories induisent des problématiques de testabilité et de planification. N – Négociable : elle doit amener à la discussion et peut-être modifiée jusqu’à son inclusion dans une itération. V – Valeur : elle doit apporter de la valeur à l’utilisateur final. La notion de valeur étant toujours difficile à évaluer, la user story doit être exprimée avec une vision de l’objectif recherché pour l’utilisateur. E – Estimable : elle doit être suffisamment claire et comprise par l’équipe pour que celle-ci soit en capacité de l’estimer. S – Small : elle doit être de taille assez petite pour prioriser de façon sûre et éviter les effets tunnels. Essayez donc au maximum de découper finement vos user stories. T – Testable : la user story doit raconter une histoire, dont les tests découlent de façon évidente. INFO : The INVEST mnemonic was created by Bill Wake[1] as a reminder of the characteristics of a good quality user story
  10. Une "erreur" classique consiste à partir d'un cahier des charges rédigé en amont et le découper en User Stories en s'appuyant sur sa structure textuelle. Cela peut être une bonne approche pour une équipe débutante mais ne constitue pas une pratique recommandée.
  11. Reco : organiser des ateliers Vision, Personas, User Story Mapping et Roadmap avec les parties prenantes
  12. Ne doit pas être un découpage technique: un écran, une boîte de dialogue, un bouton ne sont pas des User Stories.
  13. Une User Story ne correspond pas à un quelconque découpage technique. Reco : Changez la formulation pour raconter une histoire !
  14. Le niveau de détail évolue au fil du temps, en fonction de l'horizon de planification : une User Story dont la réalisation est prévue dans plusieurs sprints ne sera décrite que d'une brève phrase, alors qu'une User Story dont la réalisation est imminente doit être enrichie par des tests fonctionnels, des critères d’acceptations, des exemples, des maquettes, etc.
  15. Les User Stories sont beaucoup trop précises, jusqu’aux moindre détails Exemple : un champs par user story pour chaque élément le constituant. Reco : Echanger avec les développeurs pour connaitre le niveau de détail attendu dans les users stories.
  16. Les User Stories sont beaucoup trop précises, jusqu’aux moindre détails Exemple : un champs par user story pour chaque élément le constituant. Reco : Echanger avec les développeurs pour connaitre le niveau de détail attendu dans les users stories.
  17. La User Story est beaucoup trop grosse pour entrer dans un sprint
  18. Une story trop grosse pour entrer dans un sprint est une Epic. N’hésitez pas à redécouper vos grosses stories même si elles tiennent dans un sprint. Cela facilitera le suivi, les tests, et le niveau de confiance sur l’atteinte des objectifs du sprint. Reco : Pour manger l’éléphant, il faut donc le couper en tranche
  19. Pas dans la doc Scrum classique. C’est une règle de routards de l’agilité, issue de l’expérience. Cette règle va encore plus loin que la précédente dans la mesure où elle nous demande de découper les stories à un grain suffisamment fin pour en prendre plus de 4 dans un sprint. Il faut qu’un développeur puisse travailler sur plus qu’une story pendant le sprint. Si une story occupe un développeur sur la totalité du sprint, il se crée un effet tunnel qui risque de mettre le sprint en péril. Les estimations c’est un peu le jeu des devinettes. Nous savons qu’elles sont globalement vraies mais précisément fausses. Cette marge d’erreur peut conduire à ne pas pouvoir terminer une story dans le sprint où nous la planifions. Si vous ne prenez que 4 stories dans un sprint et que vous n’en terminez pas une, c’est 1/4 de l’objectif qui n’est pas réalisé. Ce qui est relativement important, à plus forte raison si la story est de taille importante.
  20. « done », ou « not done » Pas enseignée dans de nombreuses formations agiles. Passage en force mettent à mal la Définition du Done (DoD), qui est pourtant un élément essentiel de confiance entre le PO et l’équipe. C’est également un élément de mesure dans Scrum car elle contribue au calcul de la vélocité. Mettre à mal sa DoD est une promesse de complications à court terme. Que faire alors avec ces stories « not done » ?
  21. OUI, reporter l’intégralité des points totalement les points, quel que soit l’état d’avancement des stories concernées. Bien souvent, celles-ci avaient de toute façon été sous-estimées. Si l’on ne reporte pas les points, on risque de sous-estimer le contenu du sprint suivant, et donc de se retrouver à nouveau avec des stories non terminées. Et progressivement, sprint après sprint, on se construit un matelas de stories « not done » qui prend du volume. Très vite, la vélocité ne signifie plus rien, donc les projections ne signifient plus rien, donc le PO ne comprend plus l’avancement, et tout ça risque de se terminer en un vaste règlement de comptes. Pour résumer : je ne compte pas une story « not done » dans la vélocité constatée d’un sprint, et je la compte entièrement dans les points prévus pour le sprint suivant, sachant que ce total de points doit être toujours cohérent avec la vélocité constatée des derniers sprints. Cette méthode peut paraître un peu radicale (ou inutile pour les détracteurs de la vélocité), mais l’impact ne sera jamais vraiment significatif car toutes vos stories prises dans le sprint sont suffisamment petites pour éviter les grosses variations de vélocité.
  22. Bien que la comparaison entre les deux notions soit souvent utile, il n'est pas possible d'établir un lien simple et direct.
  23. User Story = brève description d’une fonctionnalité telle que vue par l’utilisateur Use Case = représente une séquence d’actions qu’un système ou tout autre entité peut accomplir en interagissant avec les acteurs  Une User Story est une promesse de conversation et le Use Case est un enregistrement de la conversation « a story is a promise to have a conversation and a use case is the record of the conversation”.
  24. Ne soyez pas dogmatique ! L’équipe sait ce dont elle a besoin pour commencer à travailler. C’est donc elle qui va pouvoir dire si une user story est prête ou non, et ce quelque soit son formalisme ! Dans certaines équipes, la user story réduite à son stricte minimum suffira, dans d’autres, la user story ressemblera à une mini spécification. La longueur d’une user story peut refléter la distance qui sépare l’équipe de son Product Owner.