4.4Backlog, user stories & estimation (planning poker)
L'essentiel en 30 secondes
- Backlog : liste priorisée et vivante de tout ce qui apporterait de la valeur.
- User story : « En tant que…, je veux…, afin de… » — la valeur avant la technique.
- Réflexe : estimer en points (relatif) au planning poker (Fibonacci), pas en jours.
Mini-cas filé — Bilal écrit le backlog avec le client
Pour nourrir ses sprints (4.2) et son flux (4.3), Bilal doit clarifier le besoin : avec le client, il reformule 5 demandes en user stories (« En tant que…, je veux…, afin de… »), les priorise par valeur, puis l'équipe les estime en points au planning poker. Le backlog est né — et il restera vivant.
Suite du cas 4.1-4.3 — Bilal outille la valeur avant d'outiller le suivi.
1. Le backlog et les user stories
En agile, le travail à faire vit dans le backlog produit : une liste priorisée et évolutive de tout ce qui apporterait de la valeur. Ses éléments s'expriment souvent en user stories : « En tant que [rôle], je veux [action] afin de [bénéfice] ».
Cette formulation garde le focus sur la valeur pour l'utilisateur, pas sur la solution technique.
2. Estimer en points
Pour estimer, l'agile préfère souvent les points (mesure relative de complexité/effort) aux durées absolues, via le planning poker : chacun estime avec des cartes (suite de Fibonacci), on discute les écarts, on converge.
On estime en équipe, on priorise par valeur, et on ajuste au fil des sprints.
🔎 Exemple concret — 🔎 Exemple concret — Pourquoi des points, pas des jours
Comparer plutôt que prédire.
L'humain compare mieux (« c'est 2× plus gros ») qu'il ne prédit des durées.
Points = effort relatif, indépendant de qui fait et des interruptions.
→ la vélocité (points/sprint) permet ensuite de prévoir sans fausse précision.Résultat : un pilotage par la valeur, sans fausse précision.
Réflexe : une bonne story est INVEST (dont « testable »).
Vocabulaire de la section
- Backlog produit
- Liste priorisée et évolutive de tout le travail à valeur du produit. Le PO en est responsable.
Exemple simple : Le backlog de Bilal, tenu par Amine, ordonne les 5 stories par valeur.
Ce que ce n'est pas : un cahier des charges figé signé une fois pour toutes.
Réflexe : à chaque sprint : réordonner et affiner, jamais figer.
- User story
- Expression d'un besoin côté utilisateur : « En tant que…, je veux…, afin de… ». Centrée sur la valeur.
Exemple simple : « En tant que client, je veux suivre ma demande afin d'éviter les appels ».
Ce que ce n'est pas : une spécification technique décrivant la solution à coder.
Réflexe : sans « afin de » crédible, la story n'est pas prête.
- Points (story points)
- Mesure RELATIVE de l'effort/complexité d'une story, préférée aux durées absolues en agile.
Exemple simple : Cette story vaut 5 points : 2 fois plus grosse qu'une story à 2.
Ce que ce n'est pas : un nombre de jours promis au client.
Réflexe : comparer les stories entre elles, jamais convertir 1 point = 1 jour.
- Planning poker
- Technique d'estimation collective où chacun propose une valeur (cartes Fibonacci), puis on discute et on converge.
Exemple simple : L'équipe de Bilal vote 3, 5, 8 : on fait parler les extrêmes puis on revote.
Ce que ce n'est pas : le PO qui impose seul ses chiffrages en jours.
Réflexe : les écarts sont de l'or : faire parler les votes extrêmes.
- Priorisation
- Ordonner le backlog par valeur (et effort), pour toujours travailler sur ce qui compte le plus d'abord.
Exemple simple : Bilal fait d'abord la story à forte valeur et faible effort.
Ce que ce n'est pas : traiter les demandes dans l'ordre d'arrivée.
Réflexe : toujours savoir ce qui est en haut du backlog — et pourquoi.
En pratique — En pratique — Rédiger et estimer un backlog
- Formulez 5 besoins en user stories : « En tant que [rôle], je veux [action] afin de [bénéfice] ».
- Priorisez-les par valeur pour l'utilisateur (et effort) : qu'est-ce qui apporte le plus, le plus vite ?
- Estimez-les en points via un planning poker : chacun propose (Fibonacci : 1,2,3,5,8…), discutez les écarts, convergez.
- Gardez le backlog vivant : on le réordonne et on l'affine à chaque sprint selon les apprentissages.
Script prêt à dire — faire écrire une vraie user story (30 s)
« Reformulons ce besoin côté utilisateur : en tant que qui ? Il veut faire quoi ? Afin d'obtenir quel bénéfice ? Tant que le “afin de” n'est pas clair, on ne priorise pas et on n'estime pas. Qui propose la première version ? »
À dire en atelier backlog : le « afin de » est le test qui sépare la story de la spec technique.
Modèle copier-coller — fiche backlog + estimation
STORY : En tant que ___, je veux ___ afin de ___.
VALEUR (forte / moyenne / faible) : ___ | RANG : ___
ESTIMATION (planning poker, Fibonacci) : ___ points
VÉLOCITÉ ÉQUIPE (points/sprint) : ___ | PRÉVISION : ___ sprints
AFFINAGE PRÉVU (date) : ___TPE / petit budget
5 stories sur cartes papier, estimation à main levée en Fibonacci : le rituel compte plus que l'outil.
Équipe distante
Votes simultanés en ligne (cartes masquées puis révélées) pour éviter l'ancrage sur le premier avis.
PME Algérie
Bilal fait valider chaque « afin de » par un vrai utilisateur local, pas par un intermédiaire.
Backlog énorme
N'estimer finement que le haut du backlog ; le bas reste en gros grains jusqu'à ce qu'il remonte.
✓ Bonnes pratiques
- Formulez les besoins côté utilisateur (le « afin de » est essentiel).
- Estimez collectivement en points, pas en durées absolues.
- Gardez le backlog vivant et priorisé par valeur.
✗ Pièges fréquents
- Rédiger des specs techniques au lieu de user stories.
- Estimer en jours absolus (fausse précision).
- Figer le backlog au lieu de l'affiner à chaque sprint.
Points clés à retenir
- Le backlog produit est la liste priorisée et évolutive du travail à valeur.
- Les user stories expriment le besoin côté utilisateur (rôle/action/bénéfice).
- L'agile estime souvent en points (effort relatif), pas en durées absolues.
- Le planning poker fait estimer l'équipe collectivement (Fibonacci).
Défi 48h — appliquez demain
Écrivez 5 vrais besoins en user stories avec leur « afin de », priorisez-les par valeur, puis estimez-les en planning poker (modèle ci-dessus).
- Je sais écrire une user story complète (rôle/action/bénéfice).
- Je distingue points (relatif) et jours (fausse précision).
- Mon backlog de 5 stories est priorisé et estimé.
Questions fréquentes
Pourquoi estimer en points plutôt qu'en jours ?
Parce que l'humain est meilleur pour comparer (« c'est deux fois plus gros que ça ») que pour prédire des durées absolues. Les points mesurent l'effort relatif, indépendamment de qui fait le travail et des interruptions. Au fil des sprints, l'équipe mesure sa « vélocité » (points réalisés par sprint), ce qui permet de prévoir sans se piéger avec de fausses précisions en jours. Une estimation en jours donne une illusion de précision que les aléas démentent vite.
Qu'est-ce qui fait une bonne user story ?
Une bonne story est centrée sur la valeur utilisateur (le « afin de » est essentiel), indépendante, négociable, estimable, assez petite pour tenir dans un sprint, et testable (on sait dire quand elle est « faite »). On résume souvent ces qualités par l'acronyme INVEST. Une story n'est pas une spécification technique : c'est une conversation à avoir autour d'un besoin. Le « afin de » rappelle en permanence pourquoi on fait la chose.
Comment s'exprime un besoin dans un backlog agile ?