How to estimate user stories

A practical guide for agile teams · Updated September 2026

Estimating a user story isn't about predicting the exact hour it will be finished. It's about getting the team to agree on how big the work is, so you can plan a sprint with reasonable confidence.

Story points, not hours

Most agile teams estimate in story points. A point is a relative measure of size that reflects three things together: how much work there is, how complicated it is, and how much is still unknown.

Relative sizing works better than hours because people are much better at comparing two pieces of work ("this is about twice as big as that one") than at guessing an absolute duration. Hours also vary from person to person, while a story's size doesn't.

Choose a scale

Many teams use a Fibonacci-style sequence: 1, 2, 3, 5, 8, 13, 21. The gaps get wider as the numbers grow, which reflects a real effect: the bigger a story is, the less precisely you can know its size. Arguing over whether something is a 14 or a 15 is wasted effort, so the scale doesn't allow it.

Some teams prefer T-shirt sizes (XS, S, M, L, XL). The principle is the same: agree on a small set of sizes and stick to it.

Pick a reference story

Choose a story the whole team understands well, and agree on its size, for example "the login page rework was a 3". Every new story is then compared with it: is this bigger, smaller or about the same? A shared reference keeps estimates consistent from sprint to sprint.

Run the session, step by step

1. Present the story. The product owner explains what is needed and the acceptance criteria.
2. Ask questions. The team clarifies scope, dependencies and anything unclear before anyone estimates.
3. Estimate privately. Everyone chooses a size at the same time, without seeing the others. This avoids anchoring, where the first number spoken sways everyone else.
4. Reveal together. Show all the estimates at once.
5. Discuss the gaps. If the estimates differ, ask the highest and lowest to explain their thinking. Differences usually reveal a hidden assumption or a missed task.
6. Vote again. Repeat until the estimates are close, then record the agreed number and move on.

When a story is too big

If a story keeps landing at 13 or above, or the team can't agree, it's usually too large to estimate well. Split it into smaller stories that each deliver something useful. Common ways to split:

• By workflow step (for example, search, then filters, then saving results)
• By business rule or variation (one payment type first, others later)
• By data or platform (one user type or one device first)
• Happy path first, edge cases and error handling afterwards

If the real problem is missing knowledge, agree a short, time-boxed investigation (a "spike") and estimate the story afterwards.

Common mistakes

• Converting points into hours. Once points become hours, you've lost the benefit of relative sizing.
• Estimating alone. The value is in the conversation. One person's estimate hides what the others know.
• Letting the most senior person speak first. Vote privately, then discuss.
• Treating estimates as promises. They are forecasts that help planning, not commitments.
• Comparing velocity between teams. Each team's points mean something different, so the numbers can't be compared fairly.

After the session

Track how many points your team completes each sprint. After a few sprints this average, called velocity, gives you a realistic basis for forecasting how much the team can take on. Re-estimate a story only when you learn something that changes its size, not because time has passed.