26 July 2011

How do I manage multiple teams release plans when using story points?

Here are a few thoughts for you.

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
There are some other assumptions that should be addressed when digging into this topic as well.

  • 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?


  1. Anonymous7:14 am

    Using Earned Value at the Work Package (Iteration) level and spreading the planned budget (BCWS) to the task level, then measuring physical percent complete at the Work Package level answers the question posed here.
    You then get forecasts of future cost and schedule and direct measures of the "capacity for work" in units meaningful to the decision makers - money.

    Since the cross team assessment is done through the Performance Measurement Baseline of the entire project or portfolio of projects, management now has visibility to the organizations "capacity for work."

  2. Excellent contribution. Thanks Glen.

  3. Another scaling approach is to have a single product owner and single backlog from which multiple teams pull work. This might mean shuffling the team members somewhat so that (ideally) any team could pull any backlog item and complete it.

    If you do that, you also can have a small set of reference items whose estimates are agreed to by all of the teams. Every other item in the backlog is then estimated relative to those reference items, and you end up having normalized estimates across teams.

    Are those estimates perfect? Of course not - they're estimates!! However, they're good enough for what you want to accomplish, which I believe is to have a view of the rate at which all of the teams can complete work, which in turn enables you to forecast the completion of some core set of work.

  4. Dave, another great idea. Thanks.