Story Point Baselines: How to Anchor Relative Estimates

Story point baselines give a team familiar examples to compare against.

Relative estimation works best when the team can point to completed or well-understood product backlog items and say, "This is what we mean by a two," or "This is the kind of work we call a five."

A baseline turns an abstract scale into a practical shared reference.

What a Story Point Baseline Is

A story point baseline is one or more product backlog items the team uses as anchors when estimating.

For example, a team might choose a completed item and agree it is a two. Then it might choose a larger item and agree it is a five. Future estimates can be compared against those baselines:

Is this new item smaller than our two?
About the same as our two?
Between the two and the five?
About the same as our five?
Larger than our five?

The baseline does not need to be perfect. It needs to be useful.

Teams often struggle with story points because the numbers feel meaningless. Baselines give the numbers meaning without tying them to days.

Why Baselines Matter

Story points are relative. That means every estimate is easier when the team has something to compare against.

Without baselines, team members may invent their own private meanings for the numbers. One person thinks a five means "about a week." Another thinks it means "moderate risk." Another thinks it means "a normal-sized story." Those private meanings create inconsistent estimates.

Baselines help the team use a shared scale.

They also make it easier to avoid points-to-days thinking. Instead of asking, "How many days is this?" the team can ask, "Is this more like the search filter we called a three or the account export we called an eight?"

That is the conversation story points are meant to create.

Do Not Start with a One

Many teams want to start by identifying a one-point item.

That sounds logical, but it can cause problems. If the team starts with a one, there is no room for anything smaller. The first baseline also tends to anchor the whole scale. If the team chooses something too large as a one, future estimates can become inflated.

A better approach is often to start with a small but meaningful item and call it a two.

That leaves room below it. If the team later sees something truly smaller, it can call it a one. The team can then choose another item that is roughly twice as much effort and place it at five, or something between the two and the five at three.

The exact numbers are less important than creating useful comparison points.

How to Establish Baselines

Use items the team understands.

Completed product backlog items are best because the team has real experience with them. If completed items are not available, choose items the team understands well enough to compare.

A practical approach:

Find a small but meaningful completed item.
Agree on a value, often two or three.
Find an item that is clearly larger.
Agree on a higher value, often five or eight.
Add one larger baseline only if the team needs it.
Keep the baseline list short and visible during estimation.

Do not build an elaborate catalog of examples. A few good anchors are usually enough.

The team should revisit baselines occasionally, especially if estimates start drifting or new types of work become common.

Use Baselines During Estimation

Baselines should be visible during estimating conversations.

When a team estimates a new item, compare it with one or more baseline items:

"This feels larger than the login change we called a three."
"It has less work than the export feature we called an eight, but more uncertainty than the filter change we called a five."
"If that old item was a five, I cannot see this being a thirteen."

This comparison is sometimes called triangulation. The team checks the new estimate against multiple known items rather than estimating in isolation.

Triangulation is especially useful when someone proposes an estimate that feels high or low. It keeps the discussion grounded in previous decisions.

Baselines Help Prevent Estimate Inflation

Estimate inflation happens when items receive more points today than similar items would have received in the past.

It often starts innocently. A team is unsure whether an item is a two or a three. Because the team is under pressure to increase velocity, it chooses three. The next item is slightly larger, so it becomes a five. Soon the scale has drifted.

Baselines are one of the best defenses.

When estimates start creeping upward, compare new items with old baseline items. If a new item looks like a known three, call it a three. Do not let pressure on velocity redefine the scale.

Publicly reviewing estimates during Sprint Reviews can also help. Teams are less likely to put a large estimate on obviously small work when the estimate will be visible in a practical context.

Shared Baselines Across Multiple Teams

A shared baseline can help when several teams work from one product backlog or contribute to a shared release forecast. It should be treated as a forecasting aid, not a productivity comparison. The goal is a common language for product backlog item size, not a league table of teams.

Story points normally belong to one team. A team’s estimates, baselines, and velocity all develop together, so one team’s five-point item may not mean the same thing as another team’s five-point item.

Most of the time, that is fine. Teams can estimate with their own baselines and use their own historical velocity for planning.

Shared baselines become useful when multiple teams need to contribute to one product forecast, work from one product backlog, or estimate work that could be done by more than one team. In those cases, teams can choose a few product backlog items they all understand and agree how those items should be estimated.

The goal is to create enough shared reference points that cross-team planning is less misleading, not to make every team identical.

Use shared baselines carefully. They are useful for forecasting and coordination. They should not be used to compare teams by velocity or decide which team is faster.

Common Baseline Problems

The Baseline Is Too Abstract

A definition such as "a five is medium" is less useful than a real item the team has completed. Use examples.

The Team Has Too Many Baselines

A large catalog becomes hard to remember and maintain. Keep a small set of anchors.

Baselines Are Secretly Time-Based

If a two means two days, the team has not established a story point baseline. It has created a time estimate in disguise. For more detail, see 7 Ways to Get the Best Estimates of Story Size.

The Baseline Never Changes

Baselines should be stable, but not frozen forever. If the team's work changes significantly, refresh the examples.

Management Uses Baselines to Compare Teams

Baselines can support multi-team planning. They should not be used to decide which team is faster based only on point totals.

How to Choose Good Baseline Items

Good baseline items are familiar, representative, and easy for the team to discuss.

Look for items that:

The team has already completed or understands well.
Represent real product backlog work, not artificial examples.
Include the full effort to finish, not just coding.
Are small enough to remember clearly.
Are not emotionally loaded or controversial.
Cover a few useful values, such as 2, 5, and 8.

Avoid using a strange one-off item as a baseline. If the item had unusual politics, unusual technology, or unusual rework, it may distort future comparisons.

The team does not need a baseline for every value. It needs enough anchors to make comparison easier.

Use Baselines to Triangulate

Triangulation means checking an estimate against more than one baseline.

Suppose the team thinks a new item is a five. Before recording that estimate, it can ask:

Is it clearly larger than the two-point baseline?
Is it clearly smaller than the eight-point baseline?
Is it similar to other five-point items we have completed?
What risk or uncertainty could push it into the next bucket?

Triangulation helps prevent drift. It also helps the team catch estimates that were influenced by optimism, pressure, or one person’s strong opinion.

Baselines Should Represent Total Effort

A baseline should represent the total effort to deliver a product backlog item.

If the team chooses baselines based only on coding effort, future estimates will ignore testing, analysis, design, database work, review, deployment, documentation, and other work needed to get the item done.

This matters because story points estimate effort, not just technical complexity. A baseline item that involved simple code but extensive testing may be larger than it first appears. A technically tricky item may be small if the scope is narrow and the team knows the area well.

When choosing baseline items, ask what work was actually needed to finish them.

When to Refresh Baselines

Baselines should be stable enough to support comparison, but not so permanent that they become outdated.

Refresh or replace a baseline when:

The team no longer remembers the item clearly.
The product, architecture, or tooling has changed significantly.
The baseline was based on an estimate the team no longer trusts.
The team has changed enough that the old comparison no longer helps.
The baseline is encouraging points-to-days thinking.

Do not change baselines just to make velocity look better. That is estimate inflation. Refresh baselines to preserve a useful shared reference, not to improve the numbers.

Baselines Can Help Leaders Too

Baselines can help leaders understand story points without converting them to days.

Instead of saying, "Five points equals about three days," a Product Owner can say, "A five-point item is similar in effort to these two items we finished last quarter."

That keeps the conversation grounded in relative size. It also helps stakeholders discuss scope tradeoffs without treating every point as a fixed time commitment.

FAQ

How many baseline items do we need?

Start with two or three. Add more only when the team repeatedly needs another comparison point.

Should baselines be completed items?

Completed items are best. The team has learned what was actually involved. Well-understood upcoming items can work when completed examples are not available.

Can we change a baseline estimate later?

Usually leave the old estimate alone. The baseline represents how the team calibrated at the time. If it is no longer useful, replace the baseline with a better example.

Should every story point value have a baseline?

No. That usually creates too much overhead. A few anchors are enough for most teams.

Can baselines help a new team?

Yes, but use them lightly. A new team may start with a few sample items, then refine its baselines after it has completed real work together.

Can baselines help multiple teams use story points together?

Yes, when multiple teams need to contribute to the same forecast or work from the same product backlog. A few shared baseline items can help teams estimate more consistently. But shared baselines should support planning, not team comparison.

Last updated August 5th, 2026