How teams estimate: sizing user stories with story points

Why estimation goes wrong

Ask a developer "how long will this take?" and you get a number in hours or days. Ask again a week later and the number has changed. Nobody lied. The work had parts nobody could see yet.

Most estimation problems come from this gap. Teams are asked for a precise time before they understand the work, and then the number becomes a promise.

Hours or story points?

There are two common ways to estimate work in a software team.

Time estimates (hours or days) are easy to understand and easy to plan a calendar with. They break down when the work is new, because people are bad at predicting time for things they haven't done before.

Story points are relative. You don't say "this takes 6 hours". You say "this is about twice the size of that story we already finished". Points combine three things in one number: effort, complexity and uncertainty.

The Scrum Guide doesn't require either one. It says the Developers who will do the work are responsible for sizing it. Points, hours and T-shirt sizes are all choices the team makes.

How sizing with story points works

1. Pick a reference story. Choose a small story the whole team knows well and call it a 2 or a 3. Every new story is compared to it.
2. Use a scale with gaps. Most teams use a modified Fibonacci scale: 1, 2, 3, 5, 8, 13, 20. The gaps grow because bigger work is harder to estimate precisely. Nobody can tell a 14 from a 15.
3. Estimate together. The people doing the work estimate it, including QA. A senior developer alone will size the coding and miss the testing.
4. Split anything too big. If a story lands at 13 or above, the team doesn't understand it well enough. Break it into smaller stories before it enters a Sprint.

Planning Poker in five minutes

Planning Poker was first described by James Grenning in 2002 and later popularized by Mike Cohn in Agile Estimating and Planning. It is the most common way teams assign points.

• The Product Owner reads the story and answers questions.
• Everyone picks a card privately.
• All cards are revealed at the same time.
• The highest and lowest voters explain their reasoning.
• The team votes again, usually once or twice, until the numbers are close.

Revealing at the same moment matters. If the tech lead speaks first, everyone else anchors on that number.

The discussion between the high and low votes is the most valuable part. Someone who votes 8 when everyone else votes 3 often knows about a legacy module, a missing API or a test environment problem.

Mistakes that ruin story points

• Converting points to hours. Once "1 point = 4 hours" becomes a rule, you are back to time estimates with extra steps.
• Comparing teams by velocity. Points are relative to each team's reference story. Team A's 40 and Team B's 25 can't be compared.
• Using velocity as a performance target. If people are judged on points, points inflate. The number stops meaning anything.
• Re-estimating after the work is done. The estimate was the team's best guess at the time. Keep it, and learn from the difference in the Retrospective.

Where LazyScrum fits

LazyScrum runs Estimation inside a live Sprint Planning session on top of your Jira data. The team estimates together in the same session, team members join planning free, and you see capacity and the timeline while you estimate, so the Sprint you commit to is one the team can actually finish.

LazyScrum offers a 7-day free trial. Try it here.

Now we want to hear from you

How does your team estimate today? Story points, hours, T-shirt sizes, or no estimates at all? Who joins the session, and how often does the estimate match reality?

Share this post with your team and ask them the same question. The answers are usually more interesting than you expect.