Story points are abstract. They represent the volume of work in a backlog relative to the capacity of that team. This relativism means that a team’s velocity is constant in its context but not across multiple contexts.
Velocity via story points does not directly enable you to forecast how much work a team can deliver when;
- They have a different product owner
- They swap onto different technology
- When the make-up of the team changes substantially (ie new project teams are formed)
- For comparing multi team performance
- What is the minimum information is required to make project and portfolio decisions?
- Why are we forecasting and how much accuracy is required?
- What are the cross team dependencies and why do we need tools to compare productivity?
Once you have thought through these questions you may still need to find a way to normalise team story point velocities. Some ideas are presented below, and they may be useful. If they aren’t you can invent other methods, and of all else fails just go back to estimating in team days.
Workshop norms across teams
Bring people together in small groups to estimate common or similar stories. Have the teams talk about how the new estimates are the same as or different from their team estimates, and why. Talk to the teams about resetting their standards. You can also use this process to induct new agile teams into an estimating standard.
Use reference data
Similar to the above example, but standard stories from various size categories are posted up in everyone’s team area near or where they do their estimates to act as reference points for when the team do their own estimating.
“Let’s see, this sounds like example story C, so I’ll rate this as a 5 pointer.”
This is probably best introduced via an exercise where the goals are explained and some facilitated estimations are done
Simplify your measures
Move away from story points to simpler measures such as S-M-L. It’s easier to compare across teams and it’s proven successful enough in many teams already.
Use regression analysis
Look back and take objective measures of requirements using a standard (e.g. function points, or your own simplified version) and just work out what each team delivers per local story point. Then you have a translator that can help you work out the averages per team.
Forget the abstract and use the release schedule
Most of the time what matters most is integration and dependency between teams. You need to work out when to start team A on an activity to it can be ready for team B to work on a downstream component.
Simply take a look at the release plan and see when things are due to be rolled out. Factor in uncertainty, change your backlog priorities as needed and problem solved.
Have you got any other ideas? Do you use any of these techniques? Git any suggestions?