Backlog du Produit et User

stories
Backlog du produit (Product Backlog)
• Un backlog = un référentiel des exigences
• Un backlog = une liste ordonnée de toutes les choses à faire.
• Les éléments du Backlog sont appelés des user stories

• On distingue :
• le backlog du produit qui énumère les exigences avec le point
de vue du client
• le backlog du sprint qui contient les tâches de l’équipe pour
un sprint particulier
2
User story
• Une User story est une exigence à développer, formulée en une ou deux
phrases dans le langage de l’utilisateur.
• Les User Stories émergent au cours d’ateliers de travail menés avec le
Product Owner ou les Utilisateurs.
• Quelques Exemples :
• “En tant que recruteur, je peux déposer des offres d’emploi”;
• “En tant que jeune diplômé, je peux créer un CV”;
• “En tant que jeune diplômé je peux modifier un CV”;
• “En tant que jeune diplômé je peux sélectionner des offres

3
Format d’une User story

En tant qu’acheteur en ligne,

je veux pouvoir ajouter des items à mon panier supprimer les items
afin de pouvoir n’acheter que ce dont je suis vraiment certain

4
 Rédiger de bonnes User stories
Principe INVEST
• I : Indépendante
lorsque le client peut en toute liberté décider de l’ordre dans lequel les scénarios sont implémentés, sans
qu’interviennent des contraintes techniques.
• N : Négociable
un bon scénario fait état d’un objectif à atteindre, les détails d’implémentation pouvant être négociés en cours
de route entre clients et développeurs. Une US n’est pas une description technique d’une solution particulière.
• V : Verticale
une US décrit une fonctionnalité complète de l’application, dont le client peut apprécier la valeur et l’intérêt
(business value).
• E : Estimée
Les US doivent être décrites d’une manière claire et compréhensible.
• S : Suffisamment Petite
pour faciliter la planification, les US doivent être réalisables en peu de temps pour que l’équipe de
développement puisse en planifier plusieurs U.S. dans la même itération.
• T : Testable
un excellent moyen pour s’assurer que tout le monde, client et développeurs, comprend ce que recouvre un
scénario consiste à se demander comment on va le tester.
5
Principe Bon exemple d’une US
En tant que client, je veux consulter la
Indépendant liste des factures émises afin de tenir
compte des échéances de payements.
En tant que client, je veux connaître le
Négociable montant total des factures impayées
Un bon découpage qui fait apparaitre les
Vertical scénarios distincts rendus par le service
de facturation :
• Consulter la liste des factures émises
(US1)
• Afficher la liste des factures
ordonnées par date (US2)
• Afficher la liste des factures par
adresse de livraison (US3)
• Consulter une facture client (US4)
Mauvais Exemple
En tant que client, je veux créer
la liste des factures pour pouvoir
les consulter plus tard.
En tant que client, je veux,
lorsque je clique sur le bouton
«calculer» une ligne s’ajoute et
on affiche sur cette ligne le
montant total des factures
impayées.
Créer la base de données pour le
module de facturation.
Créer l’interface graphique pour
la facturation
6
Principe Bon exemple d’une US Mauvais Exemple
En tant qu'utilisateur, je peux m’inscrire Garantir le respect des règles de
Estimé sur le site en utilisant mon e-mail gestion en vigueur.
R1 : si le nom de l’utilisateur existe déjà,
lorsque l’acheteur en ligne essaye de
créer son compte, alors le message «cet
e-mail existe déjà doit »être affiché.
R2, un rabais de 5% est octroyé pour tous
les clients dont le montant total de la
facture dépasse les 1000$.

Un bon découpage qui fait apparaitre les réaliser le module de facturation

Suffisamment scénarios distincts rendus par le service – il faudra découper –
petit de facturation : ….

En tant que client, je veux connaître la Absence de tests d’acceptation

Testable liste des factures par date.
Test d’acceptation : afficher la liste des
factures ordonnées par la date de
facturation
7
Exemple 1
• Voici une user story définie pour un logiciel d’assurance auto :

En tant qu’internaute, je peux naviguer sur le site, saisir mes

informations personnelles et celles du véhicule, et soumettre
une demande en ligne, Afin d’obtenir une couverture
d’assurance automobile.

• Que pensez vous de cette user story?

8
Solution
En tant qu’internaute, je peux
naviguer sur le site, saisir mes
informations personnelles et
celles du véhicule, et
soumettre une demande en
ligne, Afin d’obtenir une
couverture d’assurance
automobile.
• Trop de choses mentionnées
• Pas suffisamment Petit (le S du INVEST)
• REGLE :
• pas de User Story composée
• Éviter les ET (et OU)
• Éviter les ‘à moins que’, ‘excepté pour’…
• Solution
• Découper en plusieurs US
9
Solution
Ici on découpe en 3 User Stories :
• « En tant qu’internaute, je peux naviguer sur le site, Afin de
choisir la couverture d’assurance automobile qui me convient »

• « En tant qu’internaute, je peux saisir mes informations

personnelles et celles du véhicule, Afin de comparer les offres
d’assurance automobile »

• « En tant qu’internaute, je peux soumettre une demande

d’assurance automobile en ligne, Afin d’obtenir un contrat »
10
Exemple 2
• Un responsable de stock écrit la U.S. suivante
C’est une U.S.
mal décrite
avec bcp
d’ambiguités

• « la bonne quantité » : quelle valeur ? Quelle unité ?

(produit unitaire, palette, chargement camion,…)
• « coûts trop élevés » : idem, subjectif --> valeur seuil
• « nous allons vendre » : quand ? demain, la semaine
prochaine ? 11
Description type d’une story
• Plan type
• En tant que <acteur>, je veux <un but> [afin de <une justification>]
• En tant que client, je veux consulter mon compte bancaire en ligne afin de d’éviter le
déplacement à la banque
• Priorité
• Nombre de points
• Représente le niveau de difficulté intrinsèque, en fonction de la taille et de la
valeur métier
• Tests d’acceptation
• Etant donné <le contexte> quand je <événement> alors <résultat>

12
 I
Tests d’acceptation: exemple N
V
E
• Vérifier qu’un email d’annulation est envoyé au voyageur et à l’hôtel S
• Vérifier que si elle a lieu au moins 15 j. avant la date prévue, pas de charge
imputée au voyageur T
• Vérifier qu’un client premium peut annuler n’importe quand sans charge
suppl.
• Vérifier qu’un client non premium paie 10% du montant de la réservation si
annulation moins de 15 j. avant la date prévue

13
Post-it de story

Numéro des stories

Numéro de story pré-requises

Importance
pour le client (/5)
Durée estimée

Points/Difficulté (/5)

14
Tâche
• A l’exécution, une story se décompose en tâches

Sprint 2 : 21/08, 14/09

Objectif : gérer les inscriptions

Stories à faire à finir fini

Story A Tâche 4 Tâche 2 Tâche 3 Tâche 1

Story B Tâche 6 Tâche 7 Tâche 5

Story C Tâche 8 Tâche 9

Tâche 10

15
 Notion d’épics

• Les épics peuvent être décrites comme un composant majeur de

l'application.

• Ils sont généralement identifiés avant que les user stories ne soient
écrites pour cartographier les plus gros composants du futur produit,
mais sont également définis plus en détail au fur et à mesure que les
user stories sont identifiées.

• Les user stories sont ensuite regroupées dans ces épics.

16
17
Hiérarchiser le Backlog Produit
• Bien que le Product Owner est le responsable du PB, le refinement des
US se fait d’une manière collaborative avec l’équipe de
développement lors d’une réunion.
 On appelle cette réunion « Product Backlog Grooming »

• Parmi les objectifs de cette réunion:

• PRIORISER les U.S.
• ESTIMER les U.S.

18
Méthode pour prioriser les U.S.
La méthode MOSCOW ou FISPE (Fonctions indispensables, souhaitables, possibles,
éliminées) propose une échelle de hiérarchisation des besoins où les lettres ont la
signification suivante :

• M pour « Must have » (Indispensable) qui sont les exigences fondamentales du produit, qui le
rendent inutilisable si elles ne sont pas développées. Elles définissent le sous-ensemble minimal
utilisable que l’équipe s’engage à réaliser.

• S pour « Should have » (Souhaitable) qui désigne les besoins importants, mais non fondamentaux
pour que le système fonctionne ; dans un contexte de délais contraignants, ils sont secondaires par
rapport aux « M ».

• C pour « Could have » (Possible) sont des besoins recensés mais considérés comme un confort
supplémentaire au fonctionnement du système.

• W pour « Want to have but Won’t have » (souhaité mais non réalisable pour le moment, donc
Eliminé) sont les besoins non prioritaires qui sont reportés à des versions ultérieures. 19
Méthode MoSCoW
1) On prépare 4 fiches :
2) En équipe, on place les User Stories sur les fiches
• Soit l’un après l’autre, soit par vote : argumentation, débat
• Max 8 par fiche

REGLE : tous les items MUST devront être finis sur les 2
premiers sprints

20
Quantifier la valeur client
• Une fois la liste priorisée des user stories, on attribue une
valeur globale au projet (par ex. 100 ou 500 points) et on répartit
les valeurs sur les US
• En restant cohérent avec les priorités

21
Estimer l’effort
• Une fois les US affectées de valeur Métier avec le PO, l’équipe va
quantifier l’effort nécessaire pour les réaliser
• 2 méthodes d’estimation
• T-shirt Size
• Planning Poker

22
 T-shirt Size
• Certains préfèrent attribuer un niveau de difficulté aux US plutôt que
lui donner une valeur d’effort
• Plus facile de comparer une tâche par rapport à une autre
• Méthode du T-Shirt Size : on choisit les catégories XS, S, M, L, XL
• Soit définir une référence : M = 2 jours
• Soit choisir une User Story étalon, connue et maitrisée, et lui affecter l’effort
qui va bien.
 Ex. : développer l’interface de saisie de commande Client estimé
• Mesure de l’effort « relatif »
 l’interface de saisie des infos Client = 2x plus long, disons M
https://www.c-sharpcorner.com/article/agile-story-point-estimation-techniques-t-shirt-
sizing/#:~:text=T%2Dshirt%20Sizing%20is%20one,usually%20used%20in%20agile%20projects.&text=With%20T%2Dshirt%20measuring%2C%2
23
0the,%2C%20or%20double%20extra%2Dlarge.
Estimation des points d’une story
• Planning Poker (source Wikipedia)
• Les participants s'installent autour d'une table, placés de façon que tout le monde puisse se voir.
• Le responsable de produit explique à l'équipe un scénario utilisateur (user story).
• Les participants posent des questions au responsable de produit, discutent du périmètre du scénario,
évoquent les conditions de satisfaction qui permettront de le considérer comme "terminé".
• Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son
estimation et la dépose, face vers le bas, sur la table devant lui.
• Au signal du facilitateur, 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é.
• Une procédure optimisée consiste, après la première "donne", de demander aux deux acteurs ayant produit
les évaluations extrêmes d'expliquer leurs points de vue respectifs. Ces explications achevées et comprises
de tous, une nouvelle estimation est produite et c'est alors la moyenne arithmétique de ces estimations qui
est prise en compte.

24
La PRIORISATION : je retiens
• Il s’agit de trier les U.S. selon la valeur Métier, définie avec
les utilisateurs ou le client

• On hiérarchisera le Backlog en fonction de leur VALEUR

métier, et de l’EFFORT estimé (étape suivante)

• Définir la valeur Métier n’est pas évident (notion d’utilité, de

désir, de facilité et fréquence d’utilisation etc.)

• Méthode MoSCoW pour prioriser les besoins selon leurs

valeurs métier 25
26
Vidéo intéressante

27