By Simon Sovič, Senior Product Manager
Story points confuse a lot of product managers. Not because the concept is hard, but because teams use them differently, argue about them in sprint planning, and then ignore the data they produce. If you have ever walked out of an estimation session thinking "that felt pointless," this guide is for you.
By the end, you will know how to introduce story points, calibrate them with your team, use them to forecast delivery, and avoid the traps that make estimation theatre instead of a planning tool. No prior agile certification needed. Expect around 15 minutes of reading and immediate actions you can take before your next sprint.
What You'll Need
- A backlog with at least 10 user stories or tasks
- A development team you can run estimation sessions with (even async)
- A project tracking tool such as Jira, Linear, or Shortcut
- Two or three completed sprints worth of historical data (helpful but not required to start)
- Basic familiarity with sprint planning and agile ceremonies
Step 1: Understand What Story Points Actually Measure
Story points are a unit of relative effort, not time. A 5-point story is roughly twice the work of a 2-point story when you account for complexity, uncertainty, and volume of work combined. They are not hours. Treating them as hours is the single most common mistake teams make, and it poisons every downstream forecast.
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is the standard scale because the gaps between numbers grow as work gets harder to estimate precisely. A 13-point story should feel uncomfortable to commit to in one sprint. That discomfort is useful signal.
- Effort includes: code complexity, testing surface, cross-team dependencies, and unknowns
- Effort does not include: calendar time, meetings, or who is doing the work
- One person's 5 and another person's 5 should roughly agree after calibration
Step 2: Set a Baseline Story (Your Reference Point)
Pick one completed story your whole team agrees was straightforward. This becomes your reference story, typically pegged at 2 or 3 points. Every future estimation starts with the question: "Is this more or less effort than that story?"
Write the reference story somewhere visible in your planning tool. Pin it in your team Slack channel or add it as the first card in your estimation template. Without a reference point, estimation drifts and becomes meaningless within three sprints.
- Choose a story that touched multiple layers of the stack, not a one-line fix
- Revisit your reference story every quarter as the codebase and team change
- If the team disagrees on what the reference story is worth, that disagreement is worth 20 minutes of conversation before you estimate anything else
Step 3: Run Planning Poker (or Async Estimation) Correctly
Planning poker works when everyone votes simultaneously before discussing. The discussion only starts after the votes are revealed. If the team talks first, anchoring bias takes over and the loudest voice wins instead of collective judgment.
For remote or async teams, tools like PlanITpoker, Parabol, or even a simple anonymous Google Form work well. The rule stays the same: reveal simultaneously, then discuss the outliers.
- Only discuss when there is a gap of two or more Fibonacci steps between the highest and lowest vote
- Ask the highest and lowest voters to explain their reasoning, not defend it
- Cap estimation discussion at 5 minutes per story. If you cannot agree, split the story or flag it as a spike
- A "spike" is a time-boxed research task used when a story is too uncertain to estimate reliably
Step 4: Track Velocity Over Time
Velocity is the number of story points your team completes per sprint on average. It is not a performance metric. It is a forecasting tool. A team with a consistent velocity of 32 points per sprint can reliably commit to roughly 32 points next sprint.
Use a rolling average of the last three to four sprints rather than all-time history. Teams change size, the codebase changes, and context shifts. Old data dilutes accuracy.
- Only count stories marked "done" by your team's definition of done, not "in review" or "deployed to staging"
- Do not pressure the team to hit a velocity target. That converts velocity from a measurement into a performance pressure, and teams respond by inflating estimates
- Expect velocity to vary by 15-20% sprint to sprint. That is normal, not a failure
If you are operating as a part-time orFractional product manager, tracking velocity is especially valuable week to week. A fractional PM typically works across two or three products simultaneously, each with its own team cadence. Understanding what each team ships per sprint tells you where to focus your limited hours. For a deeper look at how fractional PMs structure their time, see our guide on How to onboard as a new product manager at a startup, which covers the first 30 days in detail.
Step 5: Use Story Points to Forecast, Not Just Plan Sprints
Once you have three or more sprints of velocity data, story points become a forecasting tool. Divide the total points in your backlog by your average velocity to estimate how many sprints remain until a milestone.
Example: 160 points left in the backlog, average velocity of 34 points per sprint. That is roughly 4.7 sprints, or about 9.4 weeks on a two-week sprint cycle. Share this as a range, not a date. "Between 9 and 11 weeks depending on scope changes" is honest. "Done by July 3" is not.
- Update forecasts every sprint, not just at the start of a quarter
- When scope is added, show stakeholders how it shifts the forecast. This is one of the most powerful uses of story point data for managing expectations
- Build a simple burndown chart in your tracking tool. Most tools generate this automatically once you log points correctly
Step 6: Recalibrate When the System Breaks Down
Story points stop working when teams inflate estimates to feel safe, deflate them to please managers, or stop updating completed points in the tool. Watch for these signals:
- Velocity spikes or crashes with no explanation
- Stories consistently carry over from one sprint to the next
- Team members say "we always estimate 8 for anything we're unsure about"
- Stakeholders start quoting velocity numbers in performance reviews
When you notice these patterns, run a brief retrospective focused only on estimation. Ask the team: "What made our estimates wrong last sprint?" Fix the process, not the people.
Maintaining discipline around any process takes consistent effort. If you find yourself slipping on the habits that keep your planning honest, tools built around accountability can help. Best accountability tools for solopreneurs in 2026 Covers options that work for solo PMs and small teams alike.
Common Mistakes to Avoid
- Equating points with hours.This is the root cause of most story point failures. If a stakeholder asks "how many hours is a 5-point story," explain that it depends on the story, the day, and who is working on it.
- Re-estimating completed stories.Once a story ships, its points are locked. Changing them retroactively corrupts your velocity data.
- Estimating bugs and unplanned work inconsistently.Decide as a team whether bugs get estimated or tracked separately. Either approach works. Inconsistency does not.
- Using velocity to compare teams.Team A shipping 60 points per sprint is not better than Team B shipping 25 points. They have different codebases, scales, and baseline stories.
- Skipping estimation for "small" stories.A 1-point story still takes time to review and deploy. Skipping it creates invisible work that erodes velocity accuracy.
- Letting story points become a bureaucratic ritual.If your team dreads estimation, simplify the process before abandoning it entirely. Try shorter sessions, async voting, or a T-shirt sizing pre-filter before Fibonacci estimation.
Product management involves a lot of mental overhead. When the process friction compounds into stress, it affects decision quality. If that resonates, our piece on Coping with stress as a founder Addresses the habits that keep your thinking clear under pressure.
FAQ
What does a fractional product manager actually do week to week?
A fractional PM typically spends their time across backlog grooming, stakeholder alignment, and sprint reviews for one or more products. On a given week they might run an estimation session Monday, review analytics Tuesday, present a roadmap update Wednesday, and conduct user interviews Thursday. The key difference from a full-time PM is scope management: a fractional PM must decide where to spend limited hours, which makes tools like story point velocity especially important for knowing where teams are struggling.
How many story points should a team complete per sprint?
There is no universal target. A mature team of four engineers on a stable codebase might average 40-60 points per sprint with a 1-5 Fibonacci scale. A newer team might average 15-25. The number matters less than its consistency. Establish your own baseline over three sprints and work from there.
Should story points include testing and code review time?
Yes. Story points reflect total effort to reach "done," and done should include testing, code review, and any deployment steps your team defines. If you exclude these, your estimates will consistently underperform because the actual work always includes them.
What happens if the team refuses to use story points?
Find out why first. Common reasons include bad past experiences with points being used against the team, distrust of the process, or genuine preference for time-based estimates. You can try T-shirt sizing (XS/S/M/L/XL) as a lighter alternative that still gives you relative effort data without the friction of Fibonacci numbers. The goal is forecasting ability, not adherence to a specific notation.
How often should we recalibrate our baseline story?
Revisit it every two to three months, or whenever the team composition changes significantly. Technology shifts (migrating to a new framework, adding a major service dependency) also warrant a recalibration. Schedule a 30-minute session, review two or three recent stories, and confirm the reference story still feels right relative to them.
Built with SuperDuperSEO