Aggregate Velocity
✥ ✥ ✥
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
PBIs
PBIs
PBIs
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
PBIs
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
PBIs
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
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
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:
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.✥ ✥ ✥
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 |