As a recovering agile coach*, I’m sometimes asked a question about the make up of an ideal agile team. The idea of having scrum teams around 7-9 people is well known. It’s also well known that they should be cross disciplinary, and that there are only 3 official team roles in Scrum: Scrummaster, Product Owner, and then everybody else (because they are supposed to be cross-disciplinary and doing whatever is necessary to finish the sprint). I get this and fully support those concepts.

A client planning for growth

That’s all textbook Scrum, but nonetheless I sometimes have intelligent clients ask for more hands-on advice with more specific team roles, like this recent question from one of our development clients at AgilityFeat…

I know rules of thumb are inexact, but are there any headcount ratios that you subscribe to for these roles?

  • Requirements analysts to developers
  • Developers to testers
  • Project managers to (requirements analysts + developers + testers)

I’m trying to work on a staffing model and I keep finding myself consistently surprised about how the bottleneck moves around my dev team as soon as I add another person. That makes sense, of course. But with some of those ratios in mind, I’m hoping to anticipate it a little better.

I wrote him back with a long answer, which made me think I should put this up on our blog too.

The ideal agile team is…


This scrum team I coached possessed an awesome beard and one unbearded team member who always sat down during standups. It is a little known part of the agile manifesto that only team members with great beards are allowed to sit during standups.

Since an ideal scrum team is 7 people +/- 2 supposedly, I suggest the ideal scrum team makeup is the following:

  • 1 Scrummaster
  • 1 Product Owner / Requirements Analyst
  • 1 Tester
  • 1 UX/Designer
  • 4 Developers

Here comes the “It Depends…”

“How many agile coaches does it take to screw in a light bulb? No one knows, because they won’t ever give you a straight answer.” – crappy joke I just made up

Like any good consultant, I couldn’t just give my client a straight answer of how he should structure his development teams. There are a lot of qualifiers to the above “ideal” team makeup I just gave. Your experiences may vary … these are just based on our experiences in our AgilityFeat teams, and in other companies where I have coached agile teams.

The Disclaimers and Fine Print


The scrummaster can usually scale to 2 or maybe 3 teams if they are only a Scrummaster/PM, but should only work on 1 team if they also have other duties on the team besides being a Scrummaster.

Product Owners and Requirement Analysts

The agile ideal to me is that the Requirements Analyst and the Product Owner are one and the same. The team should be communicating well enough that they don’t have to specify every little thing on the stories, and so a single person can do both roles on a 7 person scrum team. The nice thing about this is there is truly one voice for the customer, and you remove the risk of disconnect between the Product Owner and a Requirements Analyst. One less handoff is usually a good thing.

However, I have seen teams at larger companies have as many as one Product Owner and 2 Requirements Analysts for a single 15 person scrum team. While not my preference, it worked well for them because they did have a good amount of bureaucracy at the company to deal with and the architecture of their application made larger-than-usual scrum teams a reasonable solution.

In my client’s case, he needs to do more communication with teams who are not in the same time zone, and so I can see the potential of having a Requirements Analyst dedicated to each team and then a Product Owner who may be split across a couple teams. In that situation you need to be wary about that communication handoff between the Product Owner and Requirements Analyst.


Testers can potentially work on 2 teams at once, depending on the complexity of the product and regression testing. One of our teams really needs 2 full time testers for only 4 developers because testing is so complex for that application. On other teams we can share a tester across 2 teams and have a ratio more like 1 tester to 5 developers. Definitely an “it depends” situation.


In our case at AgilityFeat, UX and Design are two people who work part time on multiple projects. We have also found that UX is a great role to wear the hat of Scrummaster or Product Owner on smaller teams as-needed. In reality, we have multiple teams where our UX lead Mariana and I both wear the Scrummaster hat and trade off with each other as availability requires. This is not necessarily ideal since it can create a disconnect between us, but in our startup environment it’s a concession we make to reality, our schedules, and our sanity that has worked well overall.

The Bottleneck is always moving

The truth is, the bottleneck will always move around your team no matter how you structure it. And the bottleneck will also move around the team during certain phases of a product lifecycle (for example, during bigger releases it’s often helpful to bring in extra testing help or to have developers assist with testing of other developers’ stories).

My client is wise to try and anticipate the bottleneck and structure his teams as close to an ideal as possible, and presumably you’re pretty wise too since you’re reading this. Did I also mention that you are extremely good-looking and should hire us for your next development project? Sorry, I got distracted there…

The key is to remember that the practices of Continuous Improvement and Retrospectives are keys to any agile team so that you can always address bottlenecks as they shift around the team.

* Regarding the “recovering agile coach” bit and my cruel light bulb jokes, I jest. I love agile coaches, some of my best friends are agile coaches. I have a lot of background in agile coaching and training, but with the growth of our awesome development team at AgilityFeat, I now spend all my time working with our clients and very little time doing coaching anymore.