4.4 · Backlog, user stories & estimation (planning poker)

Niveau 4 · Expert : méthodes agiles

4.4Backlog, user stories & estimation (planning poker)

Objectif : rédiger des user stories, prioriser le backlog et estimer en points (planning poker, suite de Fibonacci).
Temps estimé : 14 min

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 — des besoins formulés du point de vue de l'utilisateur : « 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.

Pour estimer ces stories, l'agile préfère souvent les points (une mesure relative de complexité/effort) aux durées absolues, via le planning poker : chacun estime avec des cartes (souvent une suite de Fibonacci), on discute les écarts, on converge. On estime en équipe, on priorise par valeur, et on ajuste au fil des sprints.

Vocabulaire de la section

Backlog produit
Liste priorisée et évolutive de tout le travail à valeur du produit. Le PO en est responsable.
User story
Expression d'un besoin côté utilisateur : « En tant que…, je veux…, afin de… ». Centrée sur la valeur.
Points (story points)
Mesure RELATIVE de l'effort/complexité d'une story, préférée aux durées absolues en agile.
Planning poker
Technique d'estimation collective où chacun propose une valeur (cartes Fibonacci), puis on discute et on converge.
Priorisation
Ordonner le backlog par valeur (et effort), pour toujours travailler sur ce qui compte le plus d'abord.
Vérifiez votre compréhension

Comment s'exprime un besoin dans un backlog agile ?

Tuto Introduction à SCRUM (user stories & backlog)
Vidéo hébergée sur YouTube — ouvrir dans un nouvel onglet ↗

En pratique — Rédiger et estimer un backlog

  1. Formulez 5 besoins en user stories : « En tant que [rôle], je veux [action] afin de [bénéfice] ».
  2. Priorisez-les par valeur pour l'utilisateur (et effort) : qu'est-ce qui apporte le plus, le plus vite ?
  3. Estimez-les en points via un planning poker : chacun propose (Fibonacci : 1,2,3,5,8…), discutez les écarts, convergez.
  4. Gardez le backlog vivant : on le réordonne et on l'affine à chaque sprint selon les apprentissages.
Vous construisez un backlog de user stories priorisées et estimées collectivement : vous pilotez par la valeur, base concrète du travail agile.

Points clés à retenir

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.

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.

⚠️ Signaler un lien cassé ou erroné

Autres ressources

📘
Asana — User Story : guide complet (avec exemples)
asana.comFR
Recherche : « user stories / backlog / planning poker »
YouTubeFR