2020/2021

User Story

Réalisé par: Naïma Daghfous

 Vocabulaire Scrum
3 15/01/2014

 « Thème » : domaine Produit, grosse Feature

 « Feature » : grosse fonctionnalité Produit
 « Epic » : grosse story
 « User Story »(notée US) : besoin élémentaire d’un Utilisateur
 « Task » : tâche (technique) pour faire la US

 Exemple dans un Backlog

 3 15/01/2014

Feature & Epic & US

Feature Epic User Story
• En tant
qu’administrateur je
veux recevoir des
• En tant notifications
Gérer les qu’administrateur je concernant les
inscriptions veux gérer les nouvelle inscriptions
inscriptions • En tant
qu’administrateur je
veux valider/refuser les
nouvelles inscriptions
• …….
 3 15/01/2014

User Story & Task

 3 15/01/2014

User Story US

 Une user story est une exigence du système à

développer formulée en une ou deux phrases dans le
langage des utilisateurs pour servir un but.

 L’avantage des user-stories est qu’elles facilitent la

démarche en deux temps :
 générales et grossières au début,
 elles s’enrichissent ensuite d’exemples (senario), de
tests d’acceptation.
 3 15/01/2014

forme canonique d'une US

 Une user story présente une vision utilisateur autour de
3 axes : rôle, besoin et valeur métier
<En tant que> rôle, utilisateur
<Je Veux> besoin, action
<Afin de> bénéfice, valeur métier

 Pour la rédaction de vos User Stories :

Qui a fait la demande ou qui bénéficie de la demande ? ->
le rôle utilisateur
Quelle est la demande ? -> le besoin
Quelle valeur métier découle de la réalisation de ce
besoin ? -> le bénéfice

 Une user story doit être INVEST

 3 15/01/2014

INVEST
 Indépendante : une User Story est indépendante vis-à-vis
des autres User Stories du backlog. Idéalement, elle se
suffit à elle même pour éviter les dépendances avec
d'autres User Stories. Car toute dépendance génère des
problématiques de planification et de tests.

 Négociable : une User Story est un support de

discussion en vue d’une amélioration du besoin initial. Elle
peut être modifiée, on parle d'affinage jusqu'à son
intégration dans une itération ou Sprint. Généralement, on
considère qu'elle est affinée lorsqu'elle répond aux critères
de la "Définition of Ready" établie par l'équipe.
 3 15/01/2014

INVEST
 Valorisable : la réalisation d’une User Story doit rendre
un service à l’utilisateur. Elle n'a de sens que si elle
apporte une valeur métier.

 Estimable : une User Story doit être bien définie pour

être facilement estimable, quel que soit votre mode
d'estimation. Si l'équipe n'est pas en capacité de l'estimer,
c'est souvent que votre User Story manque de clarté.
 3 15/01/2014

INVEST
 Small : une User Story doit être réalisable sur un sprint,
soit suffisamment petite ou découpée de telle manière à
pouvoir être déployée sur un seul sprint et minimiser les
effets tunnels sur plusieurs sprints. Cherchez donc à
découper vos User Stories le plus finement possible.
Mieux vaut créer deux petites User Stories, qu'une
grande.

 Testable : une User Story doit raconter une histoire

dont les critères d'acceptabilité et les tests doivent découler
de manière évidente pour faciliter sa validation.
 3 15/01/2014

INVEST
 Small : une User Story doit être réalisable sur un sprint,
soit suffisamment petite ou découpée de telle manière à
pouvoir être déployée sur un seul sprint et minimiser les
effets tunnels sur plusieurs sprints. Cherchez donc à
découper vos User Stories le plus finement possible.
Mieux vaut créer deux petites User Stories, qu'une
grande.

 Testable : une User Story doit raconter une histoire

dont les critères d'acceptabilité et les tests doivent découler
de manière évidente pour faciliter sa validation.
 3 15/01/2014

Les tests d'acceptation TA

 TA: C'est un outil de communication fourni par le Product
Owner qui permet de déterminer quand une User Story est
terminée. C'est un test qui peut être écrit conjointement
avec le Product Owner, l'expert métier, un ou des devs et le
Scrum Master.
 Les test d'acceptation sont concentrés sur le QUOI plutôt
que sur le COMMENT
 Ils permettent de garantir la conformité entre la
fonctionnalité livrée et les règles fonctionnelles définies dans la
User Story. Ce qui revient à décrire des cas d'utilisation ou
scénarios de tests de cette histoire démontrables lors des
Review de fin de sprint ou démos auprès des utilisateurs par
exemple.
 3 15/01/2014

Les tests d'acceptation TA

 TA: C'est un outil de communication fourni par le Product
Owner qui permet de déterminer quand une User Story est
terminée. C'est un test qui peut être écrit conjointement
avec le Product Owner, l'expert métier, un ou des devs et le
Scrum Master.
 Les test d'acceptation sont concentrés sur le QUOI plutôt
que sur le COMMENT
 Ils permettent de garantir la conformité entre la
fonctionnalité livrée et les règles fonctionnelles définies dans la
User Story. Ce qui revient à décrire des cas d'utilisation ou
scénarios de tests de cette histoire démontrables lors des
Review de fin de sprint ou démos auprès des utilisateurs par
exemple.
 3 15/01/2014

ATDD vs BDD
 Pour la scénarisation des tests d’acceptation ATDD –
Acceptance Test-Driven Development
utilise une représentation graphique de workflow de tests,
pour discuter et formuler les scénarios de test au niveau de la
Feature ou du Processus Métier à implémenter, pour produire
des tests au niveau applicatifs et inter-applicatifs.

 BDD – Behavior-Driven Development (et aussi parfois SBE

– Specification By Example)
utilise le format textuel Given – When –Then pour définir les
scénarios de test associés au critères d’acceptation de la User
Story affinée, pour produire des tests plus atomiques et
centrés sur une User Story.
 3 15/01/2014

ATDD vs BDD
 Ces approches partagent une même philosophie : la
scénarisation des tests vise à renforcer l’expression du besoin
et les critères d’acceptation au travers d’exemples de cas
d’usage, devenant des tests d’acceptation.
Elles exprime bien les points clés :
 La scénarisation des tests d’acceptation BDD et ATDD
permet d’affiner l’expression du besoin en Agile sous la forme
d’exemples testables
 Ces scénarios de test d’acceptation formalisent ce qui est
attendu du logiciel en cours de définition et d’implémentation,
et ils représentent des exemples d’usage du logiciel
 La scénarisation des tests est partagée et compréhensible
par tous les membres de l’équipe Agile : analystes métier,
Product Owner, testeurs et développeurs.
 3 15/01/2014

US + BDD
 3 15/01/2014

Exemple

 Prenons l’exemple d’une entreprise qui souhaite

développer en interne la gestion des déplacements
professionnels au sein du logiciel RH.
 Gestion des déplacements :
Le système devra permettre de créer une mission (par un
salarié), de valider la mission (par son Manager) et de procéder
au remboursement des frais de mission par le service RH.
 3 15/01/2014

Exemple TA : Given – When –Then

 3 15/01/2014

Créer US
 3 15/01/2014

Comment Estimer?
 3 15/01/2014

Exemple:Le Planning Pocker

Estimer via le Planning Poker
 Le Planning Pocker
3 15/01/2014

 Explications du scénario utilisateur

 Questions/réponses sur le scénario utilisateur : Les participants

discutent avec le product owner du périmètre du scénario, ils peuvent
demander des clarifications du scénario…

Estimation individuelle du scénario : Chacun des participants évalue

la complexité de ce scénario, choisit la carte qui correspond à son
estimation sans la montrer.

Estimation collective : Au signal du Scrum Master, les cartes sont

retournées en même temps. S’il n’y a pas unanimité, la discussion
reprend. On répète le processus d’estimation jusqu’à l’obtention de
l’unanimité.

 Valeur d’un « story point » : A la fin, on établit la valeur en temps

d’un « story point »= travail que l’équipe de développement peut caser
dans une « timebox » dont la durée est connue.
 3 15/01/2014

Exercice
Soit la US suivante:

En tant que utilisateur je veux pouvoir

réinitialiser mon mot de passe

Proposer des taches associées à cette US

Proposer des TA (Given – When –Then )
différents
 3 15/01/2014

Solution
US :En tant que utilisateur je veux pouvoir réinitialiser
mon mot de passe

taches associées à cette US:

• Conception de la page de connexion.
• Couper les icônes et les images SVG.
• Implémenter la page de connexion HTML / CSS / JS.
• Créer des scripts SQL pour créer des tables.
• Créer une API de service Web pour les informations
utilisateurs
 3 15/01/2014

Solution
US :En tant que utilisateur je veux pouvoir réinitialiser
mon mot de passe
TA associés à cette US:
• Etant donné que je suis sur la page de
connexion, lorsque je clique sur “mot de passe
oublié” alors je suis redirigé vers la page de
réinitialisation du mot de passe
• Etant donné que je suis sur la page “réinitialiser mon mot
de passe”, lorsque je rentre l’ancien mot se passe ainsi
que deux fois le nouveau mot passe , alors j’ai une
confirmation du changement de mon passe.