How to Establish a Baseline for Story Points in a New Team

“We’ll just use Fibonacci and figure it out as we go.”

That sentence has quietly killed more velocity charts than any production outage.

Most new teams treat story points like a vague suggestion instead of a measurable system. Then they’re shocked when:

Velocity swings 40–60% sprint to sprint
Stakeholders stop trusting forecasts
Every refinement turns into a debate about “Is this a 3 or a 5?”

Here’s the uncomfortable truth:
If you don’t deliberately establish a baseline for story points, your team will create one accidentally—and it will be inconsistent, political, and hard to fix later.

This post walks through a concrete, opinionated way to establish a baseline for story points in a new team so that:

Velocity becomes meaningful in 3–5 sprints
Refinement is faster and calmer
Forecasts stop feeling like astrology

Why Baseline Story Points at All?

Before the “how,” let’s address the “why.”
Many teams secretly think: “Can’t we just estimate and learn over time?”

You can. You’ll just pay for it in:

Confused stakeholders: “Why did a 5 last sprint take 2 hours and this 5 took 4 days?”
Demoralized teams: “Our velocity is all over the place; what’s wrong with us?”
Endless re-estimation: “We keep resizing stories mid-sprint because we guessed wrong.”

Story Points Are a Relative Measurement System

Story points are like a custom unit of measure your team invents. If you don’t define the “meter stick,” your measurements are meaningless.

A baseline answers:

What does a 1-point story look like in our world?
What does a 3, 5, 8 actually mean in terms of effort and complexity?
How do we compare “add a button” vs “integrate with external API” consistently?

Without a Baseline, Velocity Is Noise

You can’t compare:

Sprint 1: 30 points
Sprint 2: 18 points
Sprint 3: 42 points

…if the team is silently changing what “5 points” means every week.

A baseline isn’t bureaucracy. It’s the foundation that makes velocity and forecasting useful.

Step 1: Define What Story Points Actually Represent

Most teams mess up here and never recover.

Pick a Clear Definition (and Stick to It)

Your story points should represent relative effort, not exact time, but they must be anchored in something concrete. I recommend:

Story points represent total effort for the team:

Development work

Testing and validation

Risk and uncertainty

Coordination/communication overhead

What story points are not:

They are not hours
They are not business value
They are not priority

Mixing those in is how you get executives asking, “Why did we spend 13 points on something low value?”

Use Time as a Sanity Check, Not a Mapping

I’m opinionated on this:
You should talk about time when creating your baseline—but you should not publish a “1 point = X hours” conversion.

Instead:

Use time ranges as internal reference:
- A 1-point story might typically be done in a few hours
- A 3-point story might take up to a day
- A 5-point story might span 1–2 days
But never promise: “We will always deliver 1 point per 4 hours.”

Time is a sanity check. Relative size is the actual unit.

Step 2: Create 3–5 Concrete Reference Stories

This is the most underused, high-leverage practice.

You don’t need a perfect scale. You need a shared reference catalog.

How to Build Your Initial Reference Set

In your first refinement or planning session:

List 10–15 upcoming stories that are:
- Real (from your actual backlog)
- Independent (not huge epics or tiny sub-tasks)
Ask the team: “Which of these feels the smallest?”
- Pick 1–2 as candidates for your 1-point story
Estimate those explicitly:
- “Could 1–2 people finish this in a few hours with almost no risk?”
- If yes → that’s your 1-point reference story
Now find a 3-point reference:
- “Which story is clearly bigger than our 1-point, but not scary?”
- Something that might take about a day, has a couple of edge cases
Then pick a 5-point reference:
- “Which one is roughly twice as big as our 3?”
- Maybe integration, some testing complexity, a few unknowns

You now have 3 concrete examples:

1-point: e.g., “Add a new field to an existing form and persist it”
3-point: e.g., “Add a new API endpoint with validation and unit tests”
5-point: e.g., “Add a new user role with permissions and update UI flows”

Write Them Down Publicly

Do not keep this in someone’s head. Put it somewhere visible:

Confluence page
Team charter
A “Story Point Reference” doc in your repo
A Miro board or wiki page

Include:

Story title
Short description
Why you labeled it 1, 3, or 5

This becomes your calibration chart.

Step 3: Use Relative Sizing Ruthlessly

Once you have references, stop “freehand estimating.”

Always Compare to the Reference Stories

When estimating a new story, ask:

“Is this more like our 1, 3, or 5?”
“Is it smaller than our 3 but bigger than our 1?” → probably a 2 (if you use even numbers)
“Is it bigger than our 5 but not twice as much?” → maybe an 8

You’re not asking, “How many points is this?”
You’re asking, “Which reference story is this closest to?”

Don’t Overuse Large Sizes Initially

I strongly recommend:

Avoid 13+ point stories in the first few sprints
If something feels like a 13 or 20:
- It’s not “big”; it’s not refined enough
- Split it until the pieces are closer to your 3–8 range

Large stories wreck your baseline because:

They hide unknowns
They inflate velocity randomly
They encourage heroics instead of collaboration

Step 4: Align the Whole Team — Not Just Devs

If only developers understand the baseline, the system will drift.

Bring Testers, Designers, and Product Into the Conversation

In your baseline session, explicitly ask:

Testers: “What kind of testing effort does a 3-point story usually require?”
Designers: “When design is included, how does that affect our sizing?”
Product: “What kind of scope changes usually blow up a 3 into an 8?”

This matters because story points represent team effort, not just coding.

Make Dependencies Explicit

If a story is “small” but blocked on:

External APIs
Other teams
Vendor timelines

…that uncertainty should be reflected in the points. Don’t pretend it’s a 1 just because the code is simple.

Common Mistakes When Establishing a Baseline (What Not to Do)

Here’s where most new teams quietly sabotage themselves.

1. Mapping Points Directly to Hours

Example anti-pattern:

“In this team, 1 point = 4 hours. Done.”

Problems:

People game the system: “This will take 2 days, so it must be 4 points.”
Velocity becomes a proxy timesheet
Context switching, risk, and complexity vanish from the equation

Use hours as a sense check, not a contract.

2. Letting the Loudest Voice Set the Baseline

If every estimate ends with, “Let’s just go with what Alex said,” you don’t have a baseline—you have a dictator.

Symptoms:

Juniors never disagree
Estimates cluster around one person’s opinion
Planning poker turns into “What do you think, Alex?”

Fix it:

Use anonymous voting (tools help here)
Always ask, “Who has the highest and lowest estimate? Why?”
Normalize disagreement as signal, not conflict

3. Changing the Meaning of Points Mid-Stream

Some teams realize after 3 sprints:

“We’re always underestimating. Let’s just double all our point sizes.”

Congratulations, you’ve just destroyed your historical data.

Better approach:

Keep the meaning of points stable
Improve your refinement and splitting practices
Let velocity naturally increase as you get better

4. Using Story Points to Judge Individual Performance

The fastest way to corrupt your baseline:

“Why did you only complete 8 points this sprint when others did 20?”
“We should give bigger stories to stronger devs.”

Story points are a team metric. Use them to:

Forecast
Improve planning
Spot systemic issues

Never to rank people.

5. Obsessing Over Precision

If you’re spending 15 minutes debating 3 vs 5, your process is the problem, not your numbers.

Rule of thumb:

If the team is split between adjacent values (3 vs 5), pick the higher and move on
If the team is split widely (2 vs 13), the story is unclear or too big—refine or split

Step 5: Calibrate Using Real Data (Sprints 1–5)

Your initial baseline is a hypothesis. Now you need to test and refine it.

Track a Few Simple Metrics

Over the first 3–5 sprints, watch:

Average cycle time per point
- Roughly: “How long does a 3-point story usually take from ‘In Progress’ to ‘Done’?”
Completion rate
- What % of committed points are done by the end of the sprint?
Distribution of story sizes
- Are most stories 5s and 8s? That’s a smell—your stories are probably too big.

You don’t need a data science degree. You just need patterns.

Run Short Calibration Retrospectives

Every 2–3 sprints, dedicate 20–30 minutes to:

Look at 3–5 recently completed stories
Ask:
- “Does this still feel like a 3 compared to our reference 3?”
- “Which stories felt mis-sized, and why?”
Update your reference catalog:
- Add one or two new examples
- Remove outdated ones that no longer reflect your work

This is how your baseline matures without constant churn.

Practical, Actionable Steps to Establish Your Baseline This Week

If you want a concrete playbook, use this.

In Your Next Planning/Refinement Session

Block 60–90 minutes and tell the team:
“Goal: establish our first baseline for story points.”
Explain your definition (5–10 minutes):
- Story points = total effort (dev + test + risk + coordination)
- Relative, not absolute
- Time is a sanity check, not a mapping
Pick your reference stories (30–40 minutes):
- Choose 10–15 upcoming backlog items
- Find your 1, 3, and 5
- Discuss why each is what it is
- Document them immediately
Estimate 5–10 more stories using the references (20–30 minutes):
- Use planning poker
- Focus on relative sizing: “More like our 3 or our 5?”
- Avoid anything above 8 points—split instead
Agree on working rules (5–10 minutes):
- No mapping points to individuals
- No re-scaling points later
- If something feels bigger than 8–13 → we split

Over the Next 3–5 Sprints

Track:
- Velocity trend
- Completion rate
- Average story size
Run a 20–30 minute calibration retro every 2–3 sprints
Update your reference catalog as your work evolves

Tools That Make Baseline Discussions Less Painful

You don’t need heavy tooling, but a few features help a lot when you’re forming a baseline:

Anonymous voting to reduce anchoring (“I’ll just pick what the senior dev picked”)
Quick, no-signup sessions for ad-hoc estimation with cross-team stakeholders
Integration with your issue tracker so estimates live with the stories, not in screenshots

A lightweight tool like ScrumPoi (free, supports planning poker + retrospectives, anonymous voting, Jira integration, no per-user cost) can make those early baseline sessions faster and less biased, especially for new or mixed-experience teams.

The Point of Story Points Isn’t the Number

If you take one thing away, let it be this:

Story points are not about mathematical precision. They’re about creating a shared mental model of work.

A solid baseline gives you:

Calm, focused refinement sessions
Velocity that actually means something
Forecasts you don’t have to apologize for

Don’t wait for “a few sprints” to magically stabilize things.
Sit down with your team, define your references, write them down, and treat your baseline as a product: start simple, measure, and iterate with intent.