Story Point Estimation Across Multiple Teams
Strategies for consistent estimation when multiple agile teams work on the same product. Covers normalization, shared reference stories, and portfolio-level planning.
Detailed Explanation
Estimation Across Multiple Teams
When multiple teams contribute to the same product, their story points are not directly comparable. A 5 for Team Alpha might be an 8 for Team Beta. Portfolio-level planning requires strategies to bridge this gap.
Why Points Do Not Compare Across Teams
- Teams have different skill sets and experience levels.
- Teams estimate relative to their own reference stories.
- Team composition changes over time.
- Different domains have different inherent complexity.
Strategy 1: Normalization Factor
Derive a conversion factor from historical data.
Team Alpha: Average velocity 30 pts/sprint, 5 developers
→ 6 pts per developer per sprint
Team Beta: Average velocity 45 pts/sprint, 6 developers
→ 7.5 pts per developer per sprint
Normalization: 1 Alpha-point ≈ 1.25 Beta-points
Caveat: This is approximate and should only be used for high-level portfolio views, never for team comparison or performance evaluation.
Strategy 2: Shared Reference Stories
Select 3-5 stories that multiple teams have worked on (or could understand) and establish shared calibration points.
Shared references:
"Add a new REST endpoint with CRUD operations" = 5 (all teams agree)
"Build a new dashboard page with 3 widgets" = 8 (all teams agree)
"Infrastructure migration of one service" = 13 (all teams agree)
Each team uses these shared references alongside their own. This does not make points identical, but it narrows the gap.
Strategy 3: T-Shirt at Portfolio Level
Abandon points entirely for cross-team planning. Use T-shirt sizes at the epic/initiative level and let each team break down and estimate in their own way.
Portfolio board:
Initiative A: XL (Team Alpha and Team Beta)
Alpha's breakdown: 45 story points
Beta's breakdown: 60 story points
Combined T-shirt: XL ✓ (consistent)
Strategy 4: Capacity-Based Planning
Instead of normalizing points, normalize capacity:
- Each team has a known velocity.
- Allocate work based on each team's capacity, not cross-team point comparison.
- Track progress as percentage of planned capacity consumed.
What to Avoid
- Standardizing points across teams -- Forces artificial consistency and creates resentment.
- Ranking teams by velocity -- Meaningless and destructive.
- Adding velocities together -- 30 + 45 ≠ 75 unless you have normalized first.
Use Case
Use this guide when a program manager or portfolio owner needs to plan across multiple agile teams, or when teams push back against point standardization.