30days until
ScrumPLoP!

Aggregate Velocity



... your product has grown to multiple teams, each one of which was drawn from the single, original team whose velocity had stabilized. The Product Owner wants to establish a new velocity for the Product Backlog.

✥    ✥    ✥

You need to know the development velocity to establish release schedules and to estimate delivery ranges for PBIs. In a single-team Scrum you can use that team's velocity, but what do you do in a multi-team Scrum?

Each team has its own velocity, and these velocities cannot trivially be averaged or normalized with each other. Just as there is a gestalt effect between team members that contributes to the high velocity of a team, so there are non-linear influences between multiple coordinated teams that can either increase or decrease their collective effectiveness.

During Sprint Planning, team members collectively estimate 
 on the product backlog based on their intuition and past experience as a team. In a multi-team Scrum each team can choose its own 
 to take into a sprint and can estimate them in isolation. If the team knows its velocity then it can forecast delivery of some set of 
. Even in a multi-team environment, an individual team could establish its velocity through experience over time. That would enable each team to select a set of 
 that the team is very likely to complete at the end of the sprint. The Product Owner can be confident in the possibility that the teams will meet their forecasts.

However, the Product Owner also predicts completion ranges for future releases and for specific PBIs. In a single-team environment the Product Owner can use the teams' 
 estimates and the team's velocity (as a range) for this calculation. However, multi-team efforts complicate the problem by raising the question of who estimates the 
 and of how to calculate velocity.

Assume that each PBI is estimated by only a single team. Each 
 will either be developed by the team that estimated it, or by another team. If all 
 are developed by the teams that estimate them, then it constrains the ownership of a 
 to teams long before development actually starts. There is a good chance that the PBIs will move up or down the Product Backlog in that interval. Consider that Team 1 estimates PBIs A, E and F, and that Team 2 estimates PBIs B, C, and D. The PBIs have the order A, B, C, D, E, F as set by the Product Owner:


If both teams have a velocity of 20, and if teams must work on the items they themselves estimated, then it is impossible both for each team to fill its sprint backlog, and to honor the Product Owner's desired ordering. If you combine this constraint with the additional constraints of dependencies between 
, or of marketing scheduling constraints, this becomes a hopelessly frustrating proble m. Note that this is true even if you have cross-functional teams.

We can conclude that if each 
 is estimated only by a single team, then the estimate isn't accurate enough for the Product Owner to calculate a range of release dates for it or for any 
 with a later delivery date — no matter who implements the 
.

We could let multiple teams take turns estimating the 
. Because teams use different baselines and have different talents, these numbers are likely to differ for different teams. You might imagine that you could make a running average over these numbers, but it doesn't make sense to average a set of numbers that were created on different scales. It's like averaging miles-per-hour with kilometers-per-hour without any reference to the conversion factor between them. Note that this, too, is true even if you have cross-functional teams.

If, on the other hand, we re-assign a 
 estimated by one team to another team to break it down into tasks for a sprint, then the original estimate bears no correlation to the actual time or cost of the 
. We should be concerned about that, because it was the original estimate that the product owner used to place this item in the Product Backlog. If we allow such re-assignment for any 
, then the 
 estimates are largely meaningless.

If there were some kind of conversion factor for velocities between teams, then we could normalize each 
PBI's
 estimate by the ratio of the velocity of team that estimated the 
 to that of the team that will implement it. However, no such conversion factors exist: team velocities can't be compared. Even if they could ideally be compared, the cost of implementing any particular 
 depends on the collective talents of the team that estimates those costs assuming that they will implement it, and the difference in talents across teams can significantly skew such estimates. And what's worse, and even more basic, a team does not feel committed to a commitment defined by someone else, even if each team is actually cross-functional.

When a team takes a PBI into a sprint, it can throw away an estimate provided by another team and use its own estimate for its commitment. But that means that the estimates on the backlog are arbitrary except those going into the current sprint.

And beyond this is the more obvious problem that it is impossible to compare the cost of two items on a product backlog: it's apples and oranges. You can't compare velocities between teams, even if each team is cross-functional. This makes it impossible for the Product Owner to make an informed ordering of the Product Backlog based on relative cost of items, all other things being equal.

You could give each team its own Product Backlog, each of which is fed by the Chief Product Owner's Product Backlog for the product. This might work if each team actually builds its own product with its own value stream and ROI. Then, it makes sense to have multiple product backlogs and to do away with the over-arching one. But if all teams contribute their own part of an integrated product, this approach reduces to the problem described above, of assigning PBIs to teams too early:


Furthermore, it complicates the Product Owner's ability to re-order PBIs.

Therefore, have all teams estimate all PBIs together, to extend the scope of consensus to all Developers. The concept of Estimation Points should be derived from the aggregate velocity of all teams together.

✥    ✥    ✥

Now the 
Product Backlog is estimated in a way that does not limit the ability to assign any PBI to any team.

There are many ways to implement this pattern. One might have each team estimate all  in isolation before taking a second pass to reconcile the teams' individual estimates. Alternatively, one might reduce the awkwardness of the exercise by removing individuals in a way that does not violate the need for a diverse estimation base.

Bulk Estimation may be a good way to solve this problem the first time the Product Backlog is estimated; however, you want to estimate items incrementally (on the basis of new information) thereafter. Repeated Bulk Estimation is wasted work.

The velocity of a set of non-specialized teams can no more be derived from the individual team velocities than a team's aggregate velocity can be computed with reference to the velocities of its individual members. If you have specialized teams, you can use Specialized Velocities.  Specialized Velocities more easily scales to a large number of teams than Aggregate Velocity does, while losing none of the "whole team" estimation one sacrifices when using the common practice of estimation by team representatives. It may also compensate for the impediment of multi-site developments.

If all teams collectively estimate each  , then teams have no individual velocities. That could dilute the sense of team commitment and could make it difficult to measure Kaizen advances on a team level.

Author: Jim Coplien