If Scrum Teams Become Too Large, They Should…

Team effectiveness suffers when teams are too large. We explain how to make adjustments to fix this problem.

Jason: So one of the questions I get a lot when I’m either in class, or working with a team is: “Our Scrum Team has grown. We’ve added some people, we’ve added some people with different skills, and it’s getting big. It’s getting unwieldy. It’s getting maybe difficult to work in the Scrum Team.” What do you guys think we should tell people about what happens when your Scrum Team gets too big? How big is too big? Robb, what do you think about that? 

Robb: That’s a fine question. As a matter of fact, the Scrum Guide has something to say about this, and let me read it for you while I put on my glasses.

“The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

That’s straight out of the Scrum Guide. So I agree with this, if your team is too big you have to find a way to break it down. But we’re not talking about creating teams that are doing different things with different focuses, just smaller units all still focused on the same things, getting value maximized by the same Product Owner, and working from the same Product Backlog.

Jason: Okay, so you take a big team, you break it into smaller teams, and focus them on the same product. That makes sense. Greg, what do you think? How would someone know that they’re at that point? How would they know if they’re at that “too big” area? I mean, is it a number of people? Is there something else that they should look for?

Greg: I think it’s less about hitting a cap of people. I think it would be more a factor of the efficacy of the team to be able to get to a done increment every single Sprint. So if your team is struggling with communication, we think likely that’s due to the number of people. There might be a way to be able to discover that after a number of Retrospectives and Sprints. If we haven’t seen improvements, maybe now is the opportunity to look at dividing that team up into multiple teams. I’ve learned that starting with five people on a team is actually a really nice sweet spot. So if you’re at that nine threshold there may be a little pressure on the efficacy of the number of people. But yeah, according to the Scrum Guide, ten or less, and that’s based on some science and based on some data. It’s not just a random number. But I would look at how effective your team is. If you’re knocking it out of the park every Sprint, you’re probably fine until you’re not. Then let’s evaluate and maybe consider that.

Jason: Yeah, the number of lines of communication goes up pretty rapidly. I’ve seen this image making the rounds on LinkedIn and Twitter of lines between different points and how quickly as you add one additional person, two additional people, three additional people, those number of lines of communication on your team go up really quickly. So it can make it really hard to manage.

Personally, I’ve seen this play out in one of my first Scrum Teams. I think there were about 12 or 15 people. While we were “one team” in theory, in practice we were really three sub-teams. We pretended we were all one big team, we attended the same Daily Scrum and we had the same Sprint Planning. But there was an area of the code that I was working in, and that a couple of us were working in, and we would never touch their area. Then there was a third area that belonged to a different sub-team. And so in practice, we really acted like three sub-teams and in retrospect, we probably should have broken up into three sub-teams, or three different teams the way the Scrum Guide suggests. Have either of you seen that in your practice? Where you’ve seen a team that really needs to split up?

Greg: I’ve seen a situation, Jason, where QA is already split up from the team. Whether they like it or not, they are part of the developers. When they are set apart, usually we see some other dysfunctions happen within the flow of work to getting something done. I don’t think many people would say, “Yeah, we have this segmented team situation going on”. But that’s exactly what’s happened. You’ve just decided to do that with testing, you’ve decided to do that with quality assurance. Many times that’s an organizational practice. That’s a standard that is very difficult to decouple and get around. I see that happen very commonly.

Robb: I’ve seen it go the other way where you’ve got teams that have already pre-broken-down to very, very, very small units like three-people teams. No team by themselves is really making a ton of progress, and there’s three of these three-people teams. My recommendation has been to do the opposite. Reform into one team like Voltron and you’ll likely have a little bit more horsepower behind your efforts.

You like that, Voltron?

Jason: I’m loving the 80’s cartoon reference.

So I’m hearing that, having a team broken out either by specialty, by skill set, is not necessarily a good thing to do because now we’re having to throw work across different teams to get any real done increment. But also that you might go too small and now the team isn’t making significant progress which is why I think the Scrum Guide does put it that way. You want to be small enough to be nimble, but big enough to complete significant work.

Anything else that we should watch out for as far as team size? 

Greg: The only thing I might add into this is, when you do it, each team is able to create a done increment. If we are building separate teams that are dependent upon each other to get to a done increment, we really haven’t done ourselves any favors. So make sure each team that is created is capable of making a done increment with the individuals on that team. I think that would be the only thing I would caution against.

Be sure to subscribe to the Responsive Advisors YouTube channel for more videos like this one!