How to set a baseline for story points with reference stories

A story point baseline is a short list of finished backlog items your team has agreed sizes for: a typical 2, a typical 5, a typical 8 and so on. These reference stories become your measuring stick. When a new item comes up, you compare it with them instead of estimating from scratch. To set one, choose a handful of recently finished stories the whole team remembers, agree their sizes, write them down with a line on why, and review them every few sprints.

A good baseline is what keeps “a 5” meaning the same thing in March as it did in January. That consistency is what makes velocity worth tracking. It also gets new team members estimating confidently within a session or two, and it speeds up refinement, because every vote starts from a shared example rather than a private guess.

What is a story point baseline?

Story points are relative, so they need something to be relative to. The baseline is that something: a small set of reference stories, each tied to a value on your scale, that the team uses to judge new work. It is not a conversion rate to hours, and it doesn’t make your 5 equal to anyone else’s 5. It just makes your 5 equal to your 5.

Without a baseline, estimates drift. A team that called a simple API endpoint a 3 in its first month may be calling similar work a 5 six months later, without anyone deciding to. Velocity seems to rise while delivery stays flat, and forecasts built on it quietly go wrong.

How to choose good reference stories

The best reference stories are ordinary. You want items the team will naturally compare new work with, not the heroic one-off everyone still talks about. Look for stories that are:

• Finished and remembered. Recent enough that people recall what the work really involved, including the testing and the surprises.
• Typical of your work. Pick the kinds of items that come up again and again, such as a new form, an API endpoint or a report.
• Spread across the scale. One each at roughly 2, 3, 5 and 8 on your Fibonacci-style scale, perhaps with a 13, so any new item can be placed between two references.
• Cross-discipline. Items that involved front end, back end and testing, so nobody’s part of the work is invisible in the comparison.
• Clearly scoped. If people disagree about what a story included, it will start arguments rather than settle them.

Why not start from a 1?

It is tempting to find the smallest item and call it 1. Mike Cohn advises against it: he prefers teams to identify both a 2-point and a 5-point story, partly because a 1 leaves no room for anything smaller without fractions. There is evidence behind the advice too. In one of Magne Jørgensen’s experiments, developers who used a small user story as their reference understated how much bigger a larger story was, an assimilation effect in which the two stories seemed more alike than they really were. His recommendation for story points is simple: avoid using a small story as the reference.

Build a reference table

Write the baseline down. A table that fits on one screen is enough, kept somewhere the team can see it during refinement. Here is an example for a team working on an online shop:

Build the table outwards from your 2 and your 5; the 1 and the 13 can come later. The “why” column matters more than it looks. It records what the team counted as part of the work, which is exactly what new members, and your future selves, need when a comparison feels off.

Setting a first baseline with a new team

A new team, or a team new to points, can set a usable baseline in under an hour:

1. Gather 8 to 12 candidate items. Use recently finished work if the team has shared history. If not, use upcoming items that everyone understands well.
2. Sort them silently. Without any numbers, arrange the items from least to most effort. Discuss only the items people keep moving.
3. Anchor in the middle. Pick a typical, mid-sized item and call it a 5. Then find a clearly smaller item, around half its size or a little less, and call it a 2.
4. Place the rest by comparison. Bigger than the 2 but clearly smaller than the 5? Call it a 3. Noticeably bigger than the 5? Try an 8.
5. Triangulate. Check each value against one smaller and one larger reference. Does the 5 feel bigger than the 3 and smaller than the 8?
6. Write the table and start using it. Treat it as a draft for the first few sprints and expect to swap a reference or two.

Using the baseline in planning poker

Once the table exists, make it part of every refinement session. The rhythm is simple: present the new story, ask which reference it most resembles, then let everyone vote at the same moment. When votes differ, ask the highest and lowest voters to explain before anyone suggests a middle value; they usually know something the others don’t. Our guide on how to run a planning poker session covers the full flow.

Two details make a surprising difference. First, don’t say a number out loud before the vote, even as a joke, because the first number people hear pulls their estimates towards it. Second, think about the order of items. Jørgensen found that estimates are influenced by the item estimated just before, so he suggests starting with a mid-sized item and avoiding sequences that jump straight from a tiny fix to a huge feature.

On planningpoker.org With a free Laya account, Reference Issues and Matching Issues in a SprintPoker session on a Laya board or a Jira board show items your team has estimated before, so the team can compare a new item with sizes it has already agreed.

Keeping a living reference set

A baseline is not set once and forgotten. Codebases change, tools change, and a story that was a 5 two years ago might be a 2 today. Review the reference set every few months, or sooner if you notice that:

• People no longer remember the reference stories, or half the team joined after them.
• New kinds of work have appeared that no reference resembles.
• Tooling has changed enough that a reference is no longer typical, such as a new PDF library that makes invoices trivial.
• Retrospectives keep finding the same estimation surprises, such as 3s that behave like 8s.

When you refresh, replace examples, not the scale. Swap an old 5 for a newer story the team agrees is the same size, and keep the meaning of a 5 steady. Resist starting a brand new baseline for each project: Cohn points out that doing so throws away all your historical velocity, and recommends keeping a team’s baseline consistent while the team and the kind of work stay broadly similar.

Getting better estimates of story size

A baseline is the foundation, but a few more habits sharpen every estimate:

• Clarify before you size. If the acceptance criteria are vague, the estimate will be too. Ask the product owner to tighten them, or size the item roughly and mark it for another look.
• Estimate as a whole team. Developers, testers and designers each see different parts of the work. An estimate from one person quietly leaves out whatever that person doesn’t do.
• Agree what an estimate includes. Coding, review, testing and release: everything your Definition of Done requires. Many nasty surprises turn out to be work someone didn’t count.
• Keep most items small. Cohn notes evidence that people estimate most reliably within about one order of magnitude. Items above 13 usually need splitting into smaller stories before they can be estimated well.
• Spike the unknowns. When the size depends on an unanswered question, time-box a short investigation and estimate afterwards.
• Write down assumptions. “Assumes the carrier API supports bulk labels” turns a future argument into a quick check.
• Use history to learn, not to blame. In retrospectives, ask which estimates surprised you and why, then update your references or your habits.

For the bigger picture of what points measure, and what they don’t, see story points explained.

Baselines across several teams

When several teams work on one product, someone eventually wants a single forecast. Cohn’s approach is to bring one or more representatives from each team together to estimate a dozen or so varied backlog items, then use those as a shared reference. It works, but it comes with a warning: managers may then assume teams can be compared on velocity alone, which isn’t the case, and pressure to raise velocity is exactly what makes estimates creep upwards.

Some scaling frameworks go further. SAFe suggests that each team find a small story that would take about a day to develop, test and validate, and call it a 1, so that points across teams are approximately normalised. That makes points easier to combine, but defining the reference by time invites people to treat a point as a day, which brings back the problems of estimating in days. Whichever route you choose, use a shared baseline to forecast the whole product, never to rank the teams building it. For more on forecasting with points, see our guide to velocity and forecasting.