USER STORIES de A à US
@martialsegura
Sommaire
 Introduction
 Exercice d’échauffement
 Les origines des User Stories
 Définition d’une User Story
 Méthode ...
3
4
Exercice d’échauffement
Spécifieurs et les artistes
Objectif : Reproduire le dessin du client.
Règles du jeu :
L’animate...
5
6
Un peu d’Histoire…
Dinosaures Préhistoire
2001
JC
0
Moyen Age
& Cycle en V
Matrice rôle-fonctionnalité
de Rachel Davies ...
7
Suite à l’arrivée de l’Agilité
Finalement, c’est comme avant
– Recueil des besoins
– Recherche d’idées innovantes
– Grou...
8
Les débuts des User Stories
… C’EST L’HISTOIRE D’UN
MEC …
9
Les 3 C de Ron JEFFRIES
Ron JEFFRIES
Carte
• Les Story sont traditionnellement écrite
sur des cartes
• Les cartes peuven...
10
«
»
Une user story est une invitation à avoir
une conversation avec son client et
l’équipe sur un sujet particulier.
Dé...
11
Définition d’une User Story
• Compréhensible par tous (pas de terme technique)
• Raconte une histoire liée à un ou plus...
12
Elle se formalise ainsi…
• Une phrase
– En tant que utilisateur, je veux faire cette action,
afin d’obtenir tel bénéfic...
13
Exemple de User Story
• User Story
– En tant que nouvel utilisateur, je veux créer un compte avec un mot de
passe sécur...
14
15
INVEST-issez dans de bonnes User-Stories !
I Indépendant des stories suivantes (et si possible des précédentes)
N Négoc...
16
Racontez vos histoires…
Sur un tableau de suivi, avec des post-it
17
Racontez vos histoires…
Sur un tableau de suivi, avec des post-it - exemple
18
Dans un tableau de suivi sous EXCEL
ID Thème Nom Story Com-
plexité
Valeur ROI Release Ordre de
priorité
1aa 1- Galleri...
19
Dans un tableau de suivi sous EXCEL
ID Thème Nom Story Com-
plexité
Valeur ROI Release Ordre de
priorité
1aa 1- Galleri...
20
Racontez vos histoires…
Avec le logiciel Jira (User Story)
21
Racontez vos histoires…
Avec le logiciel Jira (Task Board)
22
FAILS
23
Erreur courante #1
Surcharger les post-it
La Story
N°ID Complexité
Qui réalise
EPIC
Valeur métier
24
Erreur courante #1 > Recommandation
Surcharger les post-it

Recherchez constamment la simplicité !
25
Erreur courante #2
Transformer un cahier des charges en un backlog
Cahier des charges Backlog
26
Organisez des ateliers Vision, Personas, User Story Mapping
et Roadmap avec les parties prenantes pour bien démarrer !
...
27
Erreur courante #3
Une User Story peut servir à un découpage technique
28
Erreur courante #3 > Recommandation
Une User Story peut servir à un découpage technique

Changez la formulation pour r...
29
Erreur courante #4
Préciser tous les détails, dès la création de la User Story alors que j’en aurai besoin dans un spri...
30
Erreur courante #4 > Recommandation

Temps
Préciser tous les détails, dès la création de la User Story alors que j’en ...
31
Erreur courante #5
Les User Stories précisent chaque détail d’une page ou d’un processus
32
Erreur courante #5 > Recommandation
Les User Stories précisent chaque détail d’une page ou d’un processus
Echangez avec...
33
Erreur courante #6
La User Story est beaucoup trop grosse pour entrer dans un sprint
34
Erreur courante #6 > Recommandation
La User Story est beaucoup trop grosse pour entrer dans un sprint

Découpez l’Epic...
35
Erreur courante #9
N’avoir que 1 ou 2 User Stories par développeur et par sprint
Création d’un effet tunnel garanti
qui...
36
Erreur courante #9 > Recommandation
N’avoir que 1 ou 2 User Stories par développeur et par sprint
Mieux découper les US...
37
Erreur courante #10
Passer à « done », une User Story qui ne devrait pas l’être
38
Erreur courante #10 > Recommandation
Passer à « done », une User Story qui ne devrait pas l’être
1/ Ne pas compter une ...
39
Erreur courante #11
Confondre une User Story et un Use Case
User Story Use Case
40
Erreur courante #11 > Recommandation
Confondre une User Story et un Use Case

En savoir plus : http://leanmagazine.net...
41
42
«
»
Le meilleur format d’une user story est
celui qui fonctionne avec votre équipe !
N’oubliez pas !
43
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...
Des questions ?
45
Return On TIme (ROTI)
Sur une échelle de 1 à 5,
quelle note donneriez-vous à cette présentation ?
Non Bof Plutôt oui Ou...
46
Martial SEGURA
@martialsegura
Merci !
Credit PPT : http://www.slidescarnival.com/friar-free-presentation-template/425
47
Usagecommercialnonautorisé
Usagecommercialnonautorisé
Prochain SlideShare
Chargement dans…5
×

USER STORIES - bonnes pratiques, par Martial SEGURA

329 vues

Publié le

Qu'est-ce qu'une user story ?
A quoi cela sert-il ?
Comment bien les rédiger ?
Quels sont les pièges à éviter ?
Découvrez les User Stories de A à US !!! :)

Publié dans : Développement personnel
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
329
Sur SlideShare
0
Issues des intégrations
0
Intégrations
16
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • C’est parti ! Exercice d’échauffement !!
  • 1ère étape – décrite ci-dessus : Pas de dialogue que de l’écrit. Les spécifieurs préparent leur specs dans un autre lieu. => Restitution (Les spécifieurs y participent mais ne peuvent pas parler).
    2ème étape : les spécifieurs sont libres de fonctionner comme ils le souhaitent (lieu et specs) mais ils ne peuvent pas montrer le dessin original du client => Restitution (Tout le monde peut parler)

    Durée: 10mn étape 1 et 10mn étape 2
  • A l’origine de l’Histoire, il y avait les dinosaures…
  • 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)
  • 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.
  • 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.
  • Ce n’est donc ni un besoin, ni une solution, la User Story est une conversation.
  • 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) « QUOI »
    Je veux = l’action qui doit être menée (~ la solution utilisateur) « QUI »
    Afin de = le but de l’action (~ le besoin utilisateur) « POURQUOI »




  • Exemple
  • Vous voulez être aussi fort que Hulk ?
  • 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
  • Au moment d’écrire les user-stories, si on le fait sérieusement, il y a encore des transformations qui s’opérent dans le backlog.
    Ici par exemple, on réalise que l’ajout / suppression de photo n’a de la valeur que si on les affiche sur le front (même simplement). Idem pour la gallerie photo qui n’est utile que si on peut déposer beaucoup de photo.
  • Si les user-stories sont bien faites, la valeur est identifiable très facilement derrière le “afin de …”, ce qui permet d’établir une hiérarchie plus fine (ici formalisée sous forme de taille de t-shirt, mais on peut mettre des notes, ou simplement déterminer un ordre relatif sans lui associer de valeur quantifiée).
  • 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.
  • Reco : organiser des ateliers Vision, Personas, User Story Mapping et Roadmap avec les parties prenantes
  • Ne doit pas être un découpage technique: un écran, une boîte de dialogue, un bouton ne sont pas des User Stories.
  • Une User Story ne correspond pas à un quelconque découpage technique.
    Reco : Changez la formulation pour raconter une histoire !
  • Le niveau de détail correspondant à une User Story n'est pas constant, mais évolue au fil du temps, en fonction de l'horizon de planification :
    Une User Story dont la réalisation est prévue dans plusieurs semaines ne sera décrite que d'une brève phrase, alors qu'une User Story dont la réalisation est imminente doit être cadrée par des tests fonctionnels, des critères d’acceptations, des exemples, des maquettes, etc.
  • 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.
  • 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.
  • La User Story est beaucoup trop grosse pour entrer dans un sprint
  • 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
  • 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.
  • « 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 » ?
  • 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é.
  • Bien que la comparaison entre les deux notions soit souvent utile, il n'est pas possible d'établir un lien simple et direct.

  • 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”.
  • 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.
  • Présentation réalisée par Martial SEGURA
    @martialsegura
  • PAS D’UTILISATION COMMERCIALE :  Vous autorisez les autres à reproduire, à diffuser et (à moins que vous choisissiez ‘Pas de Modification’) à modifier votre œuvre, pour toute utilisation autre que commerciale, à moins qu’ils obtiennent votre autorisation au préalable
  • USER STORIES - bonnes pratiques, par Martial SEGURA

    1. 1. USER STORIES de A à US @martialsegura
    2. 2. Sommaire  Introduction  Exercice d’échauffement  Les origines des User Stories  Définition d’une User Story  Méthode INVEST  Erreurs à éviter  Conclusion
    3. 3. 3
    4. 4. 4 Exercice d’échauffement Spécifieurs et les artistes Objectif : Reproduire le dessin du client. Règles du jeu : L’animateur joue le rôle d’un client qui demande à ce que l’on reproduise un dessin. L’équipe de réalisation est composée de 2 groupes : les « spécifieurs » et les « artistes ». > Mission des spécifieurs : Fournir une description en langage naturel du dessin à reproduire. > Mission des artistes : Reproduire le dessin au mieux
    5. 5. 5
    6. 6. 6 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
    7. 7. 7 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
    8. 8. 8 Les débuts des User Stories … C’EST L’HISTOIRE D’UN MEC …
    9. 9. 9 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 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
    10. 10. 10 « » 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. 11. 11 Définition 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é
    12. 12. 12 Elle se formalise ainsi… • Une phrase – En tant que utilisateur, je veux faire cette action, afin d’obtenir tel bénéfice de l’application • Notes – Décrivent : le contexte, les cas nominaux, la documentation à disposition, les contraintes techniques particulières, etc. • Critères d’acceptation – Ils décrivent les résultat attendus de l’User Story – Ils sont accompagnés de tests fonctionnels, d’exemples ou de contre-exemples « Si l’on ne sait pas définir un test sur une demande, c’est que l’on ne sait pas ce que l’on veut vraiment ! »
    13. 13. 13 Exemple de User Story • User Story – 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 – Mots de passe sécurisés pouvant être créé : p@ssword, azerty$$, planète!75, Mot_De_Passe!
    14. 14. 14
    15. 15. 15 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
    16. 16. 16 Racontez vos histoires… Sur un tableau de suivi, avec des post-it
    17. 17. 17 Racontez vos histoires… Sur un tableau de suivi, avec des post-it - exemple
    18. 18. 18 Dans un tableau de suivi sous EXCEL ID Thème Nom Story Com- plexité Valeur ROI Release Ordre de priorité 1aa 1- Gallerie photo Ajout / Suppression de photo + visu simple En tant que visiteur, je veux voir des photos récentes des animaux et du zoo, afin de savoir si j’ai envie d’y aller R1 1ab 1- Gallerie photo Description d’une photo En tant que visiteur, je veux voir une description de ce que représente chaque photo, afin de préparer ma visite et peut-être trouver plus facilement ce que je cherche R1 1ac 1- Gallerie photo Dépôt des photos par lots + galleries multi-page En tant que visiteur, je veux voir beaucoup de photos récentes, afin de me rassurer sur la richesse du lieu R1 2a 2- Actus Voir les actus récentes + création simple En tant que visiteur, je veux voir des actus récentes sur le zoo, afin de reperer des événements qui pourraient me donner envie d’y aller R1 1bb 1- Gallerie photo Parcourir les photos (vue slideshow) En tant que visiteur, je veux afficher un diaporama pleine page (ou écran) des photos, afin d’en apprécier les détails et de les parcourir facilement R2 Racontez vos histoires…
    19. 19. 19 Dans un tableau de suivi sous EXCEL ID Thème Nom Story Com- plexité Valeur ROI Release Ordre de priorité 1aa 1- Gallerie photo Ajout / Suppression de photo + visu simple En tant que visiteur, je veux voir des photos récentes des animaux et du zoo, afin de savoir si j’ai envie d’y aller XL R1 1ab 1- Gallerie photo Description d’une photo En tant que visiteur, je veux voir une description de ce que représente chaque photo, afin de préparer ma visite et peut-être trouver plus facilement ce que je cherche M R1 1ac 1- Gallerie photo Dépôt des photos par lots + galleries multi-page En tant que visiteur, je veux voir beaucoup de photos récentes, afin de me rassurer sur la richesse du lieu L R1 2a 2- Actus Voir les actus récentes + création simple En tant que visiteur, je veux voir des actus récentes sur le zoo, afin de reperer des événements qui pourraient me donner envie d’y aller XL R1 1bb 1- Gallerie photo Parcourir les photos (vue slideshow) En tant que visiteur, je veux afficher un diaporama pleine page (ou écran) des photos, afin d’en apprécier les détails et de les parcourir facilement S R2 Racontez vos histoires…
    20. 20. 20 Racontez vos histoires… Avec le logiciel Jira (User Story)
    21. 21. 21 Racontez vos histoires… Avec le logiciel Jira (Task Board)
    22. 22. 22 FAILS
    23. 23. 23 Erreur courante #1 Surcharger les post-it La Story N°ID Complexité Qui réalise EPIC Valeur métier
    24. 24. 24 Erreur courante #1 > Recommandation Surcharger les post-it  Recherchez constamment la simplicité !
    25. 25. 25 Erreur courante #2 Transformer un cahier des charges en un backlog Cahier des charges Backlog
    26. 26. 26 Organisez des ateliers Vision, Personas, User Story Mapping et Roadmap avec les parties prenantes pour bien démarrer !  Erreur courante #2 > Recommandation Transformer un cahier des charges en un backlog
    27. 27. 27 Erreur courante #3 Une User Story peut servir à un découpage technique
    28. 28. 28 Erreur courante #3 > Recommandation Une User Story peut servir à un découpage technique  Changez la formulation pour raconter une histoire !
    29. 29. 29 Erreur courante #4 Préciser tous les détails, dès la création de la User Story alors que j’en aurai besoin dans un sprint futur
    30. 30. 30 Erreur courante #4 > Recommandation  Temps Préciser tous les détails, dès la création de la User Story alors que j’en aurai besoin dans un sprint futur Précisez les User Stories au plus proche du sprint concerné par sa réalisation !
    31. 31. 31 Erreur courante #5 Les User Stories précisent chaque détail d’une page ou d’un processus
    32. 32. 32 Erreur courante #5 > Recommandation Les User Stories précisent chaque détail d’une page ou d’un processus Echangez avec les développeurs pour connaitre le niveau de détail attendu dans les users stories ! 
    33. 33. 33 Erreur courante #6 La User Story est beaucoup trop grosse pour entrer dans un sprint
    34. 34. 34 Erreur courante #6 > Recommandation La User Story est beaucoup trop grosse pour entrer dans un sprint  Découpez l’Epic en plusieurs User Stories !
    35. 35. 35 Erreur courante #9 N’avoir que 1 ou 2 User Stories par développeur et par sprint Création d’un effet tunnel garanti qui risque de mettre le sprint en péril
    36. 36. 36 Erreur courante #9 > Recommandation N’avoir que 1 ou 2 User Stories par développeur et par sprint Mieux découper les US pour produire plus de 4 User Stories par développeur / sprint 
    37. 37. 37 Erreur courante #10 Passer à « done », une User Story qui ne devrait pas l’être
    38. 38. 38 Erreur courante #10 > Recommandation Passer à « done », une User Story qui ne devrait pas l’être 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 user stories dans le futur 
    39. 39. 39 Erreur courante #11 Confondre une User Story et un Use Case User Story Use Case
    40. 40. 40 Erreur courante #11 > Recommandation Confondre une User Story et un Use Case  En savoir plus : http://leanmagazine.net/req/a-use-case-is-to-a-user-story-as-a-gazelle-to-a-gazebo/
    41. 41. 41
    42. 42. 42 « » Le meilleur format d’une user story est celui qui fonctionne avec votre équipe ! N’oubliez pas !
    43. 43. 43 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 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
    44. 44. Des questions ?
    45. 45. 45 Return On TIme (ROTI) Sur une échelle de 1 à 5, quelle note donneriez-vous à cette présentation ? Non Bof Plutôt oui Oui Au delà de mes attentes !
    46. 46. 46 Martial SEGURA @martialsegura Merci ! Credit PPT : http://www.slidescarnival.com/friar-free-presentation-template/425
    47. 47. 47 Usagecommercialnonautorisé Usagecommercialnonautorisé

    ×