Flocci Projects

Home › Agile answers › What are story points in agile estimation?

What are story points in agile estimation?

Story points are relative units for estimating work: instead of guessing hours, the team rates each story's size against other stories, usually on the Fibonacci scale (1, 2, 3, 5, 8, 13). Points capture effort, complexity and uncertainty together, and they are what makes velocity-based sprint forecasting possible.

Why not just estimate hours?

Hour estimates fail because humans are poor at absolute estimation but decent at comparison. 'Is this bigger than the login form we built?' gets consistent answers; 'exactly how many hours?' gets optimism. Points absorb that uncertainty: a 5 means roughly the size of other 5s this team has already delivered.

The Fibonacci scale

Most teams use 1, 2, 3, 5, 8, 13. The widening gaps force honesty about uncertainty — you cannot split hairs between 8 and 9, you must choose 8 or 13. A rule of thumb: 1 is a trivial change, 3 is a solid day-ish story, 8 needs breaking down soon, and 13 means this is an epic in disguise, so split it.

How to run an estimation session

Read the story aloud, let everyone silently pick a number, reveal together, then discuss only the outliers — the person who said 2 and the person who said 8 each know something the other does not. Re-vote once and move on, because an argument over one point costs more than the point is worth.

Points in practice

In Flocci Projects every issue carries an optional story-point field, sprint scoping sums the points you pull in, and completed sprints feed the velocity trend so the commitment has a reality check. The AI backlog breakdown pre-fills draft estimates on generated issues, which the team then corrects — a faster starting line with the same team ownership.

Try it on a free Flocci Projects board

Related questions

How many hours is one story point?

There is deliberately no fixed conversion — points are relative to your team's own scale, not clock time. If a stakeholder needs dates, use velocity instead: 40 points of backlog at a velocity of 20 is about two sprints.

Who estimates — the manager or the team?

The people doing the work. Estimates imposed from outside destroy both accuracy and trust; the manager's job is the priority order, not the size.

Should bugs get story points?

Teams split on this. Pointing bugs keeps velocity honest about where capacity goes; leaving them at zero keeps velocity a pure feature-throughput number. Pick one convention and hold it, because switching mid-stream makes the velocity history meaningless.

More agile answers