User Stories

Question 1

User story

Answer 1

• une expression d’une valeur métier.
• une description simple et compréhensible d’une fonctionnalité.
• une histoire qui se raconte, créé la discussion et amène l’équipe à confirmer sa
  compréhension du besoin.
• Reposent sur deux principes Agile :
  
  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et
    régulièrement des fonctionnalitésà grande valeur ajoutée
  • La simplicité(c’est-à-dire l’art de minimiser la quantité de travail inutile) est essentielle
• Elle se doit d’être INVEST et de répondre au 3C

Question 2

Propriétés des user story
* Les 3C de Ron Jeffries

Answer 2

• Carte - Les stories sont écrites sur des cartes, les cartes peuvent être annotées avec des estimations, commentaires, etc.
• Conversation - Les détails derrière 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és correctement.

Question 3

• INVEST

Answer 3

• Independante
  
  • les user stories sont plus faciles à prioriser et à estimer si elles sont indépendantes,
  • éviter la dépendance entre les users story (grace aux mocks).
• Négociable
  
  • une bonne story capture l’essence et non pas le detail (surtout pas technique),
  • une story n’est pas un contrat,
  • laisser une flexibilité sur les user stories pour que chacun puisse donner son avis,
  • au fil du temps, l’histoire évolue.
• Valuable
  
  • une Story doit avoir une valeur métier (adieu les stories technique …)
  • définir la valeur de la user story pour montrer le bénéfice pour l’utilisateur (client),
  • représente un meilleur découpage: chaque increment permet de réaliser une partie distincte du chiffre d’affaires.
• Estimable
  
  • une bonne user story peut être estimée,
  • suffisamment précise pour être comprise et être restreintes pour que l’équipe de
    développement puisse quantifier l’effort d’implémentation
• Small (taille)
  
  • les bonnes stories sont petites,
  • les stories dans le backlog ont (de préférence) toutes la même taille,
  • la granularité s’ajuste au fur et à mesure du projet, une story ne doit pas dépasser quelques jour-hommes.
• Testable
  
  • la user story doit être fournie avec les conditions qui permettent de vérifier qu’elle correspond aux attentes des utilisateurs,
  • tout le monde peut comprendre l’objectif de la story en lisant les cas de tests.

Question 4

• SMART

Answer 4

• Spécifique
  
  • Une tâche doit être suffisamment précise pour que chacun puisse la comprendre.
  • L’action est précise, propre à la situation
  • Penser : Qui, quoi, comment, ou et pourquoi
• Mesurable
  
  • La principale mesure est “Peut on la marquer comme réalisée ?“
  • Fixer des indicateurs qui nous permettent
  • d’une part de nous assurer que nous sommes sur la bonne voie,
  • d’autre part que nous aurons atteint notre objectif avec cette action.
• Atteignable
  
  • Le propriétaire de la tâche doit être en mesure de la réaliser.
  • Il est important qu’une équipe puisse cocher « objectifs réalisés », afin de mesurer et de vérifier le niveau d’accomplissement.
• Réaliste/Pertinents
  
  • Elle peut être réalisée dans le cadre d’un sprint
  • L’effort est prévue dans le cadre du sprint par exemple
• Temps limité
  
  • fixer un temps réaliste à une tâche,
  • pas d’action à long terme,
  • déterminé un temps implique une action spécifique,
  • on fixe une date de début et d’une de fin.

Question 5

Composition d’une user story

Answer 5

• Un titre explicite :
• Par exemple : « Client détenteur d’une carte VISA règle sa commande ».
• Une phrase narrative structurée sous la forme « En tant que … Je veux … Afin de … ».
  
  • Par exemple : « En tant que client, je veux saisir mes données bancaires afin de régler ma commande en ligne avec ma carte de credit ».
  • Cette formulation permet au Product Owner d’apporter une vision orientée client et d’identifier précisément la fonctionnalité et le bénéfice attendu.
• D’un ensemble d’exigences et de critères d’acceptation :
  
  • Par exemple : «Contrôle à effectuer sur le format de carte ».
• Une fois affinée, une User Story a une valeur métier. * La valeur métier est décidée
  suite à une demande de priorisation du Product Owner à son client.
  
  • Elle permet ainsi au client de s’engager sur une priorité,
  • et au Product Owner d’indiquer la priorité métier à son équipe dans le backlog de produit.

Question 6

Forme canonique d’une User Story

• Pour bien découper les types d’utilisateurs d’une user story, posez-vous la
  question :
  * « De qui ai-je besoin d’obtenir le feedback sur la fonctionnalité ?”, pour savoir si la
  user story résout réellement son problème ou encore “Si cette fonctionnalité n’est
  pas développée, qui va en pâtir ?”.
• Affiner le “afin de” permet de clarifier la valeur apportée par la user story,
  et donc d’aider à la priorisation des user stories des prochains sprints.
  * Si vous avez des difficultés à exprimer correctement l’objectif de la user story (le
  “afin de”), raisonnez en négatif : “que se passe-t-il si on ne le fait pas ? Quels sont
  les risques?”
• Une “User Story” ça veut bien dire “histoire utilisateur”, pas “contrainte
  technique”

Answer 6

Une User Story présente une vision utilisateur autour de 3 axes :
rôle, besoin et valeur métier

Question 7

La rédaction de vos User Stories est guidée par des questions à se
poser :

Answer 7

• Qui a fait la demande ou qui bénéficie de la demande ? -> le rôle utilisateur
  * <En> rôle, utilisateur - Qui a fait la demande ?</En>
• Quelle est la demande ? -> le besoin
  * <Je> besoin, action - Quelle est la demande ?</Je>
• Quelle valeur métier découle de la réalisation de ce besoin ? -> le benefice
  * <Afin> bénéfice - Quelle valeur métier découle de la réalisation de ce besoin ?</Afin>