... 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 PBIs 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 PBIs 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 PBIs. 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 PBIs 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’ PBI 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 PBIs and of how to calculate velocity.
Assume that only a single team estimates each PBI. Each PBI will either be developed by the team that estimated it, or by another team. If all PBIs are developed by the teams that estimate them, then it constrains the ownership of a PBI 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 PBIs, or of marketing scheduling constraints, this becomes a hopelessly frustrating problem. Note that this is true even if you have cross-functional teams.
We can conclude that if each PBI 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 PBI with a later delivery date — no matter who implements the PBI.
We could let multiple teams take turns estimating the PBI. 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 PBI 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 PBI. 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 PBI, then the PBI 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 PBI 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 PBI 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 forecast. 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 if each team is estimating “its own” PBIs based on its own baseline, it is in general 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:Therefore:
✥ ✥ ✥
There are many ways to implement this pattern. One might have each team estimate all PBIs in isolation before taking a second pass to reconcile the teams’ individual estimates. Alternatively, one can just let the teams reform themselves into estimation groups that are both cross-functional and which represent the constituency of all the Development Teams. An additional benefit from of this approach is that team members bring back knowledge of the Product Backlog — a “whole product purpose” — back to the team. The two mandatory building blocks of this pattern are that all teams contribute to the estimation of each PBI, and that all members of each Development Team participate in some estimation.
If you have specialized teams (e.g., Value Areas), 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 PBI together, it could dilute the sense of each teams’ commitment to its velocity.
Reflect carefully when faced with the temptation to compare velocities between teams that one might feel is facilitated by use of this pattern. If you do conclude to compare teams, please reflect again.
Picture from: PresenterMedia.com.