How to Estimate User Stories When Your Team Is Brand New to Agile

Your Team Just Adopted Agile. Now What?

The Scrum training is done. The board is set up. The Product Owner has a backlog. And now someone says: “So, how do we estimate these?” The room goes quiet.

Estimation is one of those practices that sounds straightforward until you try it for the first time. Every guide assumes you already know what story points are, what a reference story is, and how Planning Poker works. But when your team is brand new to Agile, none of those terms mean anything yet.

This guide starts at the very beginning. No assumptions about what you already know. Just a practical path from “we’ve never estimated anything” to “we have a reliable process.”

Why Estimate at All?

Before diving into how, it’s worth understanding why. Estimation serves two purposes in Agile:

• Sprint planning: Estimates help the team decide how much work to pull into a sprint. Without them, you’re guessing at capacity.
• Surfacing risk: When the team discusses an estimate, disagreements reveal hidden complexity, unclear requirements, or different assumptions about scope. Those conversations are often more valuable than the numbers themselves.

Estimation is not about predicting exactly how long something will take. It’s about giving the team enough information to make reasonable commitments and having the right conversations about the work ahead.

Start with a Reference Story

Every estimation system needs an anchor. Without one, numbers are meaningless. “This is a 5” only makes sense if the team shares a common understanding of what 5 represents.

Here’s how to create that anchor:

• Look through your backlog (or recent work) for a story that’s medium-sized and well-understood by the whole team.
• It should be something the team has either completed recently or can easily imagine completing.
• Assign it a value in the middle of your scale. If you’re using story points, call it a 3 or a 5. If you’re using t-shirt sizes, call it a Medium.
• Write it on a card or sticky note and keep it visible during estimation sessions.

This reference story is your team’s shared language. Every future estimate starts with the question: “Compared to our reference story, is this bigger, smaller, or about the same?”

Keep It Simple: Three Sizes to Start

New teams often get overwhelmed by the Fibonacci scale. When you’ve never estimated before, trying to distinguish between a 3, a 5, and an 8 is asking a lot. Start with just three sizes instead.

• Small: Straightforward. The team knows exactly what to do. Low uncertainty.
• Medium: Moderate effort. Some moving parts, but the path is mostly clear.
• Large: Significant effort or uncertainty. Might need to be broken down before the team commits to it.

That’s it. Three buckets. For your first few sprints, this gives you enough granularity to plan without the overhead of debating fine distinctions. As the team gets more comfortable, you can expand to the full Fibonacci scale. But there’s no rush. Some teams stay with three sizes permanently and do just fine.

Running Your First Estimation Session: Step by Step

Here’s a practical script for your team’s first estimation session. Keep it to 30 minutes maximum. You’re building a habit, not running a marathon.

Step 1: Set the Reference Point (5 minutes)

Show the team the reference story. Explain what it represents: “This is our Medium. Everything else gets compared to this.” Make sure everyone understands the story and agrees it represents a reasonable middle point.

Step 2: Present the First Story (2 minutes)

The Product Owner describes a user story from the backlog. Keep the description brief. Read the story, share any relevant context, and answer any clarifying questions from the team. Don’t influence the estimate.

Step 3: Estimate Simultaneously (1 minute)

Everyone picks their estimate at the same time. If you’re using cards, hold them face down and flip together. If you’re using a digital tool, everyone submits before results are revealed. If you’re keeping it simple, count to three and have everyone hold up fingers (1 for small, 2 for medium, 3 for large).

The simultaneous reveal prevents anchoring. If the most senior person says “small” first, everyone else will be influenced by that. By revealing together, you get genuine independent estimates.

Step 4: Discuss Differences (3-5 minutes)

If everyone agrees, record the estimate and move on. If there’s disagreement, ask the people at the extremes to explain their reasoning. “You said Small and you said Large. What are you each seeing?”

This discussion is where the real value happens. Common reasons for disagreement include:

• Different assumptions about scope (“Are we including the mobile view or just desktop?”)
• Different awareness of technical complexity (“This looks simple, but the database schema doesn’t support it yet.”)
• Different interpretations of the acceptance criteria

After the discussion, re-estimate. If the team still doesn’t converge, go with the higher estimate. Better to overestimate and finish early than underestimate and scramble.

Step 5: Repeat for Remaining Stories (remaining time)

Work through as many stories as time allows. You don’t need to estimate the entire backlog. Focus on the stories most likely to be pulled into the next sprint. Aim for 5 to 10 stories in your first session.

Common Beginner Mistakes

Estimating in Hours Disguised as Points

The team assigns a 5 because they think the task will take about 5 hours. This defeats the purpose of relative estimation. Story points are about comparing work to other work, not converting time into a different unit. If your team keeps translating points to hours, go back to the reference story and practice pure comparison.

Letting One Person Dominate

In many teams, the most experienced developer’s opinion carries disproportionate weight. Other team members defer to them instead of forming independent judgements. The simultaneous reveal helps, but facilitators also need to actively invite quieter team members into the discussion. “Sarah, you estimated this differently. What’s your perspective?”

Spending Too Long on a Single Story

If the team can’t converge after two rounds of discussion, something is wrong with the story, not the estimation. Either the requirements are unclear, the scope is too broad, or there are unknowns that need to be resolved before estimation is possible. Flag it, move on, and come back after the Product Owner has added more detail.

Treating Estimates as Commitments

This is the fastest way to kill honest estimation. If the team feels punished for underestimating, they’ll pad every estimate going forward. Estimates are forecasts based on what the team knows at the time. They will be wrong sometimes. That’s expected and acceptable. What matters is that they become more reliable over time as the team calibrates.

Estimating Tasks Instead of Stories

User stories describe value delivered to a user. Tasks describe technical work. Estimate at the story level, not the task level. “As a customer, I want to reset my password” is a story. “Update the email service configuration” is a task. The team can break stories into tasks after estimation, but the estimate should reflect the whole piece of user-facing value.

When Not to Estimate

Estimation is a tool, not a ritual. There are situations where skipping it makes sense, even for new teams:

• Spikes and research tasks: Timeboxing works better than estimating for exploratory work. “Spend up to 4 hours investigating the payment API” is more useful than trying to point-estimate an unknown.
• Emergency bug fixes: If something is broken in production, fix it. Estimate it after the fact for tracking purposes if needed.
• Stories that are all the same size: If your team has broken work down so well that everything is roughly a Small, you can skip estimation and just count items.

The guiding principle: estimate when it helps you plan. Skip it when it doesn’t.

Building Team Calibration Over Time

Your first estimates will be rough. That’s not a problem. Calibration is a skill that develops through repetition, not instruction.

Here’s how it develops naturally:

• Sprint 1: Estimates are all over the place. The team doesn’t have a shared sense of scale yet. That’s normal.
• Sprint 2-3: The team starts referencing completed stories. “This feels like that login feature we did last sprint, which was a Medium.” Comparisons become more grounded.
• Sprint 4-5: Estimation sessions get faster. Disagreements are less frequent and more productive. The team has a shared library of reference stories.
• Sprint 6+: Velocity stabilises. The team can reliably predict how much work they’ll complete in a sprint. Estimation feels like a natural part of planning rather than an imposed exercise.

Speed up this process by doing a brief retrospective on estimates at the end of each sprint. Look at the stories you completed and ask: “Do those estimates still feel right?” If something estimated as Small turned out to be Large, discuss why. That conversation builds the calibration faster than anything else.

From Three Sizes to Fibonacci

Once your team is comfortable with Small/Medium/Large, you can graduate to the Fibonacci scale (1, 2, 3, 5, 8, 13) if you need more granularity. Map your existing sizes to the new scale:

• Small becomes 1 or 2
• Medium becomes 3 or 5
• Large becomes 8 or 13

The transition should feel natural, not forced. If three sizes are working well for your planning, there’s no reason to add complexity. The goal is better sprint planning, not a more sophisticated estimation scale.

Frequently Asked Questions

How do you estimate a user story you’ve never done anything like before?

Compare it to the closest thing your team has done. If nothing is comparable, that’s useful information. It means the story has high uncertainty, and it should be estimated on the higher end of your scale. Consider running a spike (a timeboxed research task) first to reduce unknowns before committing to a full estimate.

What if our estimates are always too low?

Consistent underestimation usually means the team is being optimistic about complexity or forgetting about testing, code review, and deployment time. During your sprint retrospective, look at stories that took longer than expected and discuss what was missed. Over time, the team learns to factor in the full lifecycle of a story, not just the coding.

Should the Product Owner participate in estimation?

The Product Owner should present stories and answer questions, but typically shouldn’t estimate. Estimation is the development team’s responsibility because they’re the ones doing the work. The Product Owner’s role is to clarify requirements and provide context, not to influence how the team sizes the effort.

How many reference stories do we need?

Start with one. As your team completes more work, you’ll naturally accumulate additional reference points. After a few sprints, aim to have a reference story for each level of your scale. Having a known Small, Medium, and Large makes estimation faster because the team can quickly anchor to the closest reference.

What tools do we need for estimation?

Almost nothing. For a co-located team, index cards with numbers written on them work perfectly for Planning Poker. For remote teams, free tools like PlanITpoker or built-in features in Jira and Azure DevOps handle the simultaneous reveal. The tool is the least important part. The conversation matters far more than the medium.

How long should an estimation session take?

For new teams, cap it at 30 to 45 minutes. Estimation fatigue is real, and accuracy drops sharply after the first half hour. Aim to estimate 5 to 10 stories per session. If you need more, schedule a second session on a different day. As the team gets faster, you’ll handle more stories in less time.

What is the difference between estimating and sizing?

They’re often used interchangeably, but some teams make a distinction. Sizing refers to the quick, rough categorisation of stories (small, medium, large) while estimating implies a more precise assignment of story points. For practical purposes, both serve the same goal: giving the team enough information to plan a sprint. Don’t get hung up on terminology.

When should a new team switch from t-shirt sizes to story points?

When three sizes aren’t giving you enough granularity for sprint planning. If your team keeps saying “this is a Medium, but a big Medium” or “this is somewhere between Medium and Large,” that’s a sign you need more options. Most teams make this transition after 3 to 5 sprints, but there’s no deadline. Switch when it helps, not because someone says you should.