When organizations scale agile, they’re faced with the challenge of managing multiple teams. And if you have multiple teams working on the same project, that coordination becomes more complex, particularly when creating estimates.
The teams will need to estimate and plan, and then track progress against the plan so the product owner can prioritize work and communicate to stakeholders when something will be delivered.
But working with multiple teams adds some additional challenges, including:
- How do you deal with teams that have different levels of skill and experience?
- Can you accurately estimate work without involving everyone on every team?
- Is it possible to create estimates ahead of time if you don’t know which team will do which work?
There is a solution that I’m going to share with you, but before that let’s take a look at two key mistakes most organizations make when estimating for multiple teams (and based on a discussion inside my Agile Mentors Community, these mistakes are still prevalent today):
Mistake #1: Creating estimates that don’t reflect the abilities of all teams
The first mistake tends to happen when a company handpicks a set of individuals to estimate the entire backlog. This in itself is not a bad idea (in fact I’m going to advocate you do this a little later). It’s certainly faster and more efficient than having everyone on a large team all estimate every item. And you might think that if you can just select the right people, the result will be an insightful estimate.
But that’s exactly where things tend to go wrong, because if you don’t have people who are familiar with the work to be done and truly represent a cross-section of abilities throughout all teams, you will create estimates from a very narrow (and inaccurate) perspective.
Unfortunately, this does happen in companies today: estimates are created by people who are out of touch with the work to be done, and out of touch with the teams who will be doing the work.
One of the results from this is having estimates that are far more ambitious than teams can possibly achieve (especially when these estimates are used to bid for fixed-price contracts). While a low estimate might initially delight customers and stakeholders, as the project is inevitably delayed, clients become upset, trust is eroded, and working relationships break down.
What’s worse, rarely will people blame the estimate. Instead it’s the teams that face growing pressure and criticism as they scramble to deliver on an impossible deadline.
Mistake #2: Equating story points to hours
The second mistake is when an organization tries to create consistency and predictability by insisting that a uniform definition of story points be adopted by all teams. A popular (but incorrect) way to do this is to force all teams to use a set amount of hours for one story point, for example 1 story point as 3 hours, or 3 story points for 8 hours.
Again, I can see the logic behind this: it seems like a very simple way for management to see at a glance how teams are performing.
But, it doesn’t work.
Defining a story point as equal to a number of hours eliminates the main benefit to story points, which is that the number of points given to something doesn’t depend on who will do the work. A mile is a mile is a mile regardless of whether it will be run by a fast or a slow runner. So you should not equate story points to hours.
Worse, when a story point is defined as some number of hours for all teams, management may assume that teams can be easily compared solely on their velocity, which isn’t the case.
What Should Large Projects Do Instead?
So how do you create meaningful estimates for projects that involve multiple teams?
To estimate at scale, establish a common baseline for all teams to estimate with and to use to track progress toward shared goals.
But you need to do this in a way that is representative of all teams rather than simply forcing people to accept an estimate.
Here’s how.
Get the Right People Together
The best way to establish a common baseline across multiple teams is to bring together one or more representatives from each team. How many people will vary depending on the size and number of teams on the project. If you only have two or three teams, consider having everyone participate, but for larger numbers of teams it’s more likely to be two or three people per team.
Teams should select whomever they think can best estimate. Usually this will be more senior members, but that isn’t always the case. Teams should also consider mixing up the skills their representatives have. For example, don’t send three great JavaScript developers if only a portion of the work is JavaScript.
Estimate a Variety of Backlog Items
Those representatives assemble to play Planning Poker, ideally in-person but perhaps virtually if some representatives are remote, as is likely. This group is not going to estimate the entire product backlog for what is likely a large project. No, they’re going to estimate only 10–20 items.
That means that when this meeting is over, everyone will leave with a list of 10–20 items with estimates everyone has agreed on. And each team will have one or more people who participated in creating those estimates and can share any nuances or assumptions that were made.
It’s important however that these people estimate a variety of backlog tasks. That will make it easier when teams are estimating using this baseline of estimates for the basis of their relative estimates. You don’t want to estimate 20 very similar product backlog items because that won’t help when other teams use this reference to create estimates for backlog items that are totally different.
Know that You Don’t Need Everyone to Relate to Every Item
The approximately ten to twenty product backlog items I’m recommending be estimated do not each need to be understandable by every representative. For example, a hardcore scientific calculation may be representative of the overall work on this multi-team endeavor. But a couple of estimators in the room can’t relate to that item.
That’s fine. Not every estimator needs to be able to relate to every item. Instead the goal is that most items should be understandable by most teams.
This means selecting the approximately ten to twenty items is the responsibility of those participating in the meeting. They’ll be in the best position to judge when the items they’ve chosen cover a representative breadth of the product and whether most estimators can participate in estimating most items.
Using a baseline created this way, with estimates agreed upon by representatives of each team, will enable all teams to estimate in a consistent manner.
Have You Estimated With Multiple Teams? I Want to Hear from You
I know from the discussions inside the Agile Mentors Community, that this is still a hot topic today so I’d love to know what you think. Have you estimated for multiple teams? What was your approach? What worked and what didn’t? Share your experience in the comments below.
