One team, one product, one product backlog. Release planning on that scale is simple! Let’s see why. Take a hypothetical project where we estimate about 200 points worth of work in our product backlog. Assume that our team’s average velocity is 20 points per sprint. Obviously 200 / 20 tells us it would take 10 sprints to complete the work. See, nice and simple!
Now let’s scale it up. What if we have three teams instead of one team all working on the same product from the same product backlog? The math here isn’t as simple as dividing the total size of the work by a single team’s velocity. So, how do we do it?
First let’s assume this is a fixed-scope project, so we have a reasonable idea of what we want. Our goal is to estimate when it will be available. (BTW, in future blog I will deal with fixed-date multi-team release planning, where we know the date we must ship and the question is what features will the teams collectively have available on that date.)
How we calculate the answer to multi-team fixed-scope release planning depends on whether the teams are interchangeable (fungible) or not.
Interchangeable Teams
Let’s say they are interchangeable. That means that any of the three teams can work on any of the items in the product backlog. Let’s further assume that we don’t know which team will work on a particular product backlog item—that decision will be made at the last responsible moment. So our first question is which team should estimate each item?
One approach, if the teams are small, is to have all three teams jointly estimate each item. A second approach would be to do hierarchical estimating. In that case, each team estimates all the items, and then there is final round of estimates where each team sends one member to meet and do one more unifying estimation round.
In either case, each product backlog item would have one size estimate, which would be valid for all three teams. In this situation, we can do something that we can’t usually do—we can calculate a project velocity as the sum of the individual team velocities.
PV (project velocity) = V1 (velocity team 1) + V2 (velocity team 2) + V3 (velocity team 3).
When performing agile release planning we always want to give range answers to questions like “when will you be done?” To do so, we actually need to have two velocities for each team (the team’s faster or higher velocity and the team’s slower or lower velocity). When we divide the size of the work by the team’s higher velocity, the result is the fewer number of sprints we will need. And, when we divide the size of the work by the team’s lower velocity, the result is the greater number of sprints we will need.
In our case of interchangeable teams when we compute project velocity, we really want to compute the higher and lower project velocities. The following equations illustrate the idea:
PVhigh (project velocity high) = V1high + V2high + V3high
PVlow (project velocity low) = V1low + V2low + V3low
Now we can finally answer the question of “if we have three interchangeable teams all working on the same product backlog, how do we calculate when the work will be done?”
Assume that we have the following product backlog, where the goal is to release the 10 items in the picture that are above the release line. Also assume each team can work on any item.
The answer is shown in the following formula.
To de-greek the equation, we sum up the size of the first 10 product backlog items and then divide the result by the high project velocity (this provides the fewer number of sprints in the range). Then we take the same sum of the size of the first 10 product backlog items and divide it by the low project velocity (this provides the greater number of sprints in the range).
So, the above three interchangeable team calculation is structurally identical to doing a single team calculation, except we used project velocity instead of team velocity.
Non-Interchangeable Teams
Now, let’s assume that the teams are not, in fact, interchangeable. Meaning, Team 1 has to work on stories that only Team 1 can do, Team 2 has to work on Team 2 stories, and so on. This is the reality for most organizations.
In this case we cannot calculate project velocity in a single unit of measure (since there will not be a single size estimate derived and shared by all of the teams on each product backlog item). Instead, we will rely on the key agile estimating principle of “never mix and match team numbers.” Meaning, you always have to divide Team 1’s size estimates by Team 1’s velocity, and Team 2’s size estimates by Team 2’s velocity. Never mix the numbers across teams—story points are intentionally relative and unique to each team. In other words, what one team considers a 3-point story might be an 8-point story to another team.
Here is a hypothetical example. Let’s see how we can calculate an estimated range of when the work will be done.
In this example we have one product backlog that holds all of the items for Teams 1, 2, and 3. (BTW, we could have had three separate team backlogs and the results would not be any different than what you will calculate using one backlog).
Team 1 has 300 points worth of work in the backlog, Team 2 has 400 points worth of work, and Team 3 has 500 points worth of work. I am also showing the low and high velocities of each team.
So, now it’s your turn. Go ahead and do the math. First, calculate the range of sprints required for each team to complete its work and then calculate the range answer for the whole product. It might be helpful if draw your answer using the image below. BTW, round-up fractional numbers!
Go ahead and leave your answer in the comments below. I will post an answer in the comments after a bunch of responses have been left. Don’t cheat and go looking for the answer now!
Let’s see how you did!