You can standardize how teams estimate (the scale, the Definition of Done, shared reference stories, the meaning of "done" for velocity), but you can't make one team's story point equal another's by policy. Standardize the practices that make cross-team planning possible. Be careful with anything that turns velocity into a comparison between teams, because that is where standardization usually goes wrong.
This guide covers what is worth aligning, how SAFe's normalized story points work and where they help or hurt, and how to show velocity for multiple teams without starting a league table.
Why organizations want standard story points
The motivations are usually legitimate:
- Cross-team dependencies. The platform team says an API change is "a 5." The consuming team needs to know whether that means this sprint or next month.
- Program or portfolio planning. Someone has to estimate whether a set of features across six teams fits into a quarter.
- Rolling up estimates. Adding Team A's 40 points to Team B's 25 only makes sense if a point means roughly the same thing to both.
- Moving people between teams. Engineers who switch teams have to relearn the scale.
And sometimes less legitimate:
- Comparing productivity. "Team A does 45 points, Team B does 25, what's wrong with Team B?"
Be clear which of these you're solving for. The first four can be addressed with moderate standardization. The last one can't be solved with story points at all, and trying usually damages the first four.
What to standardize and what to leave to teams
| Area | Standardize? | Why |
|---|---|---|
| Estimation scale (e.g. Fibonacci 1–21) | Yes | Mixing Fibonacci, powers of 2 and T-shirt sizes makes roll-ups impossible. One scale costs teams little |
| Definition of Done for counting velocity | Yes, a shared minimum | If one team counts "code complete" and another counts "in production," velocities measure different things |
| What gets points (bugs, spikes, chores) | Yes | Otherwise one team's velocity includes bug work and another's doesn't |
| Sprint length | Ideally, within a program | Aligned cadence makes dependency planning much simpler |
| A small set of shared reference stories | Yes, as a starting anchor | Gives teams a common "this is about a 3" to calibrate against |
| Each team's own reference stories | No, let teams own them | Teams do different work; their references should reflect it |
| Estimation technique (planning poker, affinity, etc.) | Recommend, don't mandate | The output matters more than the ritual |
| Velocity targets | Never | Targets lead to point inflation, every time |
| Cross-team velocity comparisons | Never | See below |
A useful rule: standardize inputs and definitions, not outputs. Agreeing that everyone uses the same scale and the same Done is reasonable. Requiring every team to produce 30 points a sprint is not.
SAFe normalized story points: how they work
The Scaled Agile Framework (SAFe) describes a way to give teams a common starting baseline, usually called normalized story points. As SAFe describes it:
- Find a small story that would take about half a day to develop and half a day to test. Call that 1 point, so 1 point is roughly one ideal day.
- Estimate everything else relative to that story.
- For a new team's starting velocity, give each developer and tester on the team 8 points per two-week iteration, then subtract 1 point per person for each vacation day or holiday. Leave out team leads and others who don't regularly deliver stories.
So a team with 5 developers and testers, one of whom is out 2 days, starts with 5 x 8 = 40 minus 2 = 38 points. After a few iterations, the team uses its actual velocity rather than the formula.
The goal, in SAFe's framing, is that teams start from roughly the same point size so that estimates for features spanning several teams can be added up during PI (Program Increment) planning.
Where normalized points help
- Brand-new teams get a sensible first-sprint velocity instead of guessing.
- PI planning across many teams has a rough common unit for capacity, so a feature needing work from three teams can be sized without three separate conversions.
- Reallocating people is easier if a point means roughly the same thing on every team.
- Feature-level economics (for example, the job-size input to WSJF prioritization) gets a common reference.
Where they cause problems
- They pull points back toward time. "1 point = about a day" is an explicit link to days. Over time, many teams end up estimating in days and calling them points, which brings back the problems relative estimation was meant to avoid. See story points vs hours.
- The baselines drift apart anyway. Teams start normalized, then each team's scale drifts independently with its work, people and tech. After a few quarters, "normalized" is a label, not a fact, unless you recalibrate.
- They make comparison tempting. Once points are declared equivalent, someone will put velocities side by side and ask why one team is lower. Teams respond by inflating estimates, and the normalization collapses.
- The 8-points-per-person rule is a starting estimate, not a measure of what a person should deliver. Using it as an expectation turns it into individual velocity, which is a bad idea for all the reasons in how to calculate team velocity.
A balanced position
Normalized points are a reasonable bootstrap for new teams and a workable rough unit for program-level capacity, as long as you:
- Use them for planning, not evaluation. State that explicitly and repeat it.
- Recalibrate across teams once or twice a year (below), because normalization doesn't hold on its own.
- Accept that roll-ups are approximate. "About 180 points of capacity across the train, plus or minus a lot" is honest. "183 points" isn't.
- Let each team move to its own measured velocity after 3 iterations rather than staying on the formula.
If you aren't running SAFe, or your teams don't share much work, you probably don't need normalized points at all. Shared definitions and a few common reference stories get you most of the benefit.
Velocity chart for multiple teams
Leadership often asks for one chart showing every team's velocity. You can build one that helps rather than hurts.
Do:
- Show one small chart per team (small multiples), each against its own history, with its own y-axis or a clear note that axes aren't comparable.
- Show each team's trend and range, for example "Team A: 28–34, stable." Predictability is the useful signal for planning.
- If you need a combined number for capacity planning, sum the teams' expected velocities and present it as a range: "Program capacity next PI: roughly 150–180 points."
- Add say/do ratio (completed / committed) per team. It is comparable across teams because it's a ratio of each team's own numbers.
Don't:
- Put all teams on one bar chart sorted by velocity. Whatever you say about it, people will read it as a ranking.
- Show velocity per person or per head count.
- Set the next quarter's velocity "goal" from the chart.
An example
| Team | Last 6 sprints velocity | Range | Avg say/do | Note |
|---|---|---|---|---|
| Payments | 28, 31, 30, 34, 29, 32 | 28–34 | 91% | Stable |
| Mobile | 18, 22, 25, 21, 23, 24 | 18–25 | 85% | New members in sprints 1–2 |
| Platform | 40, 38, 26, 41, 39, 42 | 26–42 | 88% | Sprint 3: major incident |
Nothing here says Platform is "better" than Mobile. It tells a planner that Payments is very predictable, Mobile is stabilizing after onboarding, and Platform is predictable apart from incident-driven dips, so leave Platform some buffer for production work. That's what a multi-team velocity view is for.
Cross-team calibration session
To keep shared definitions meaningful, run a calibration session across teams once or twice a year. It takes about 90 minutes:
- Pick 5 completed stories from different teams, spanning small to large, with enough context that anyone can understand them.
- Each team estimates all 5 independently with hidden votes, without seeing the original estimates.
- Put the results in one table and compare.
- Discuss differences, not "right answers." If Team B is consistently lower on anything touching payments, maybe they own that system and genuinely find it easier. If one team is lower across the board with no explanation, its scale has probably drifted.
- Update the shared reference stories and note any agreed changes.
The single-team version of this exercise, with a worked example and a reference-story template, is in calibrating story points.
Alternatives when you need cross-team forecasts
If the real need is "will this cross-team feature land this quarter," you don't have to force story points to do it:
- Estimate features at the program level in a different unit, for example T-shirt sizes or "team-sprints." Teams keep their own story points for sprint planning. See Fibonacci vs T-shirt sizing.
- Forecast with throughput. Count stories completed per sprint instead of points. If stories are kept roughly similar in size, throughput is comparable across teams in a way points aren't.
- Ask the teams. For a feature that needs three teams, have each team estimate its part in its own points and convert to sprints using its own velocity. Combine as sprints, not points.
Rolling out standardization
- Start with definitions, not tools. Agree on scale, Done and what gets points. That's most of the value and costs almost nothing.
- Pilot with 2–3 teams for 3 sprints, including one team that's skeptical. Adjust before expanding.
- Publish a short shared reference set (one story per size from different domains) and ask each team to add its own.
- Write down what the numbers won't be used for. "Velocity is not used to compare teams or individuals" belongs in the policy, signed off by whoever owns reporting.
- Review twice a year with a cross-team calibration session.
On tools: standardizing on one estimation tool can help, but it's less important than shared definitions. If procurement and account provisioning are slowing the rollout, Alignlee's planning poker is free, doesn't need accounts and has no participant cap, so any team can use the same scale (Fibonacci, modified Fibonacci or T-shirt) without setup. It doesn't offer SSO or a Jira sync; estimates are typed back into your tracker. The Jira planning poker guide shows that workflow.
FAQ
How do you standardize story points across teams?
Agree on one estimation scale, a shared minimum Definition of Done, and what types of work get points. Publish a small set of shared reference stories and recalibrate across teams once or twice a year. Don't try to make velocities equal or comparable; standardize definitions, not outputs.
What are normalized story points in SAFe?
In SAFe, teams start from a common baseline: a story taking about half a day to develop and half a day to test is 1 point, and a new team's starting velocity is 8 points per developer or tester per two-week iteration, minus one point per day off. It gives PI planning a rough common unit. The downsides are that it links points back to days and the baselines drift apart without recalibration.
Should you compare velocity between teams?
No. Even with standardized definitions, each team's points depend on its work, codebase and people, and comparing velocities encourages estimate inflation. Compare predictability instead (velocity range and say/do ratio), which uses each team's own numbers.
How do you show a velocity chart for multiple teams?
Use one small chart per team showing its own trend, or a table with each team's recent velocities, range and say/do ratio. If you need a combined figure, sum expected velocities as a capacity range for planning. Avoid a single chart that sorts teams by velocity.
Can different teams use different estimation scales?
They can if their work is independent, but it makes roll-ups and dependency planning harder. If teams share features or a release, agreeing on one scale is the cheapest piece of standardization you can do, and it rarely costs teams anything.