... 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 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'
Assume that each PBI is estimated by only a single team. Each
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
We can conclude that if each Product Owner to calculate a range of release dates for it or for any
We could let multiple teams take turns estimating the
If, on the other hand, we re-assign a
If there were some kind of conversion factor for velocities between teams, then we could normalize each
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
Author: Jim Coplien