4.4Backlog, user stories & estimation (planning poker)
The essentials in 30 seconds
- Backlog: a prioritized, living list of everything that would bring value.
- User story: “As a…, I want…, so that…” — value before technique.
- Reflex: estimate in points (relative) with planning poker (Fibonacci), not in days.
Running case — Bilal writes the backlog with the client
To feed his sprints (4.2) and his flow (4.3), Bilal must clarify needs: with the client, he rephrases 5 requests as user stories (“As a…, I want…, so that…”), prioritizes them by value, then the team estimates them in points with planning poker. The backlog is born — and will stay alive.
Sequel to cases 4.1-4.3 — Bilal tools value before tooling tracking.
1. Backlog and user stories
In agile, work to do lives in the product backlog: a prioritized, evolving list of everything that would bring value. Its items are often phrased as user stories: “As a [role], I want [action] so that [benefit]”.
This phrasing keeps focus on user value, not the technical solution.
2. Estimating in points
For estimating, agile often prefers points (a relative measure of complexity / effort) over absolute durations, through planning poker: everyone estimates with cards (a Fibonacci sequence), extreme votes are discussed, you converge.
You estimate as a team, prioritize by value, and adjust over sprints.
🔎 Concrete example — 🔎 Concrete example — Why points, not days
Compare rather than predict.
Humans compare better (“it is 2x bigger”) than they predict durations.
Points = relative effort, independent of who does it and of interruptions.
→ velocity (points / sprint) then allows forecasting with no false precision.Outcome: steering by value, with no false precision.
Reflex: a good story is INVEST (including “testable”).
Section vocabulary
- Product backlog
- The prioritized, evolving list of all value work on the product. The PO owns it.
Simple example: Bilal's backlog, held by Amine, orders the 5 stories by value.
What it is not: a frozen specification signed once and for all.
Reflex: each sprint: reorder and refine, never freeze.
- User story
- A need phrased user-side: “As a…, I want…, so that…”. Value-centred.
Simple example: “As a client, I want to track my request so that I avoid calls”.
What it is not: a technical specification describing the solution to code.
Reflex: with no credible “so that”, the story is not ready.
- Points (story points)
- A RELATIVE measure of a story's effort / complexity, preferred over absolute durations in agile.
Simple example: This story is worth 5 points: twice as big as a 2-point story.
What it is not: a number of days promised to the client.
Reflex: compare stories with each other, never convert 1 point = 1 day.
- Planning poker
- A collective estimation technique where everyone proposes a value (Fibonacci cards), then you discuss and converge.
Simple example: Bilal's team votes 3, 5, 8: extremes speak, then you revote.
What it is not: the PO alone imposing their day estimates.
Reflex: gaps are gold: have extreme votes speak.
- Prioritization
- Ordering the backlog by value (and effort), to always work first on what matters most.
Simple example: Bilal does first the high-value, low-effort story.
What it is not: handling requests in arrival order.
Reflex: always know what tops the backlog — and why.
In practice — In practice — Writing and estimating a backlog
- Phrase 5 needs as user stories: “As a [role], I want [action] so that [benefit]”.
- Prioritize them by user value (and effort): what brings most, fastest?
- Estimate them in points with planning poker: everyone proposes (Fibonacci: 1, 2, 3, 5, 8…), discuss gaps, converge.
- Keep the backlog alive: reorder and refine it each sprint from learnings.
Ready-to-say script — getting a real user story written (30 s)
"Let us rephrase this need user-side: as whom? They want to do what? To get which benefit? Until the “so that” is unclear, we neither prioritize nor estimate. Who proposes the first version?"
To say in a backlog workshop: the “so that” is the test separating a story from a technical spec.
Copy-paste template — backlog sheet + estimation
STORY: As a ___, I want ___ so that ___.
VALUE (high / medium / low): ___ | RANK: ___
ESTIMATE (planning poker, Fibonacci): ___ points
TEAM VELOCITY (points / sprint): ___ | FORECAST: ___ sprints
REFINEMENT PLANNED (date): ___Very small business / tight budget
5 stories on paper cards, show-of-hands Fibonacci estimation: ritual matters more than tooling.
Remote team
Simultaneous online votes (hidden cards then revealed) to avoid anchoring on the first opinion.
SME in Algeria
Bilal gets each “so that” validated by a real local user, not an intermediary.
Huge backlog
Estimate finely only the top of the backlog; the bottom stays coarse until it rises.
✓ Best practices
- Phrase needs user-side (the “so that” is essential).
- Estimate collectively in points, not absolute durations.
- Keep the backlog alive and prioritized by value.
✗ Common pitfalls
- Writing technical specs instead of user stories.
- Estimating in absolute days (false precision).
- Freezing the backlog instead of refining it each sprint.
Key takeaways
- The product backlog is the prioritized, evolving list of value work.
- User stories phrase needs user-side (role / action / benefit).
- Agile often estimates in points (relative effort), not absolute durations.
- Planning poker gets the team to estimate collectively (Fibonacci).
48h challenge — apply tomorrow
Write 5 real needs as user stories with their “so that”, prioritize them by value, then estimate them with planning poker (template above).
- I can write a complete user story (role / action / benefit).
- I can tell points (relative) from days (false precision).
- My 5-story backlog is prioritized and estimated.
Frequently asked questions
Why estimate in points rather than days?
Because humans are better at comparing (“it is twice as big as that”) than at predicting absolute durations. Points measure relative effort, independent of who does the work and of interruptions. Over sprints, the team measures its “velocity” (points done per sprint), allowing forecasting without trapping yourself in false day precision. A day estimate gives a precision illusion that hazards quickly disprove.
What makes a good user story?
A good story is centred on user value (the “so that” is essential), independent, negotiable, estimable, small enough to fit a sprint, and testable (you can tell when it is “done”). These qualities are often summarized by the INVEST acronym. A story is not a technical specification: it is a conversation to have around a need. The “so that” permanently recalls why the thing is done.
How is a need phrased in an agile backlog?