Is there a healthy interval for ratio between developers and non-developers in a SCRUM team?

Question

I have recently read this article about a good ratio between developers and software quality assurance people and I am wondering if there is a similar concept for developer / non-developers in a SCRUM team.

This is caused due to the fact that current and previous work contexts for me is very different:

• old context - SCRUM team of 5-6 developers, one tester (test cases, some manual testing), one tech-lead (highly technical, most of the time spent writing code, significant fraction during mostly technical meetings), the PO, one people manager that manages three SCRUM teams in total, a fraction of a SCRUM master. People manager is typical "formerly technical", but writes no code in this role

• current context - SCRUM team of 2-3 developers, 1/2 tester (i.e. also involved in another project), one "team leader" that should handle people manager tasks and spend a significant fraction tackling stories (i.e. writing code), the PO. The team leader is typically involved in so many meetings (both technical and non-technical) that they spend less than 10% of their time writing code

After working more than one year in each setup, I feel that the first context that has a lower ratio of non-developers to developers is significantly more efficient.

Another source of inefficiency for the second text might be related to having the same person work in both "interrupted mode" (meetings, discussions, etc.) and "focused-mode" (continuous-time allocated to a single activity such as coding), but that's outside of current question focus.

Are there any recommendations related to the ratio between developers and non-developers in a SCRUM team?

Answer 1

There are many factors that influence the ratio of developers to non-developers, including:

• The domain - for example a team working on medical software might have a particularly strong emphasis on quality
• The experience levels of the team members and their familiarity with the code base
• The amount of cross-skilling - for example some or all the team members might be able to do both development and testing

Not only are there a lot of factors that influence the ratio, but also the ideal ratio may change over time and even depending on the work the team is doing at the time.

A good approach for a team is to monitor how well the current ratio is working. For example, what is the rate of escaped defects? What is the overall codebase quality like? Based on this feedback, the team can decide if it needs to change its composition or provide knowledge-sharing or training to allow a more cross-skilled capability.

Answer 2

The only ratio you will find is 1 Product Owner and 1 Scrum Master per development team.

Anyone in a Scrum team (besides PO and SM) should strive to be a developer.

A developer may have several different duties, though. Some will be more tech-oriented and thus helping defining the architecture. Some will be more people-oriented and take the burden of representing the team on discussions with other peers. Some will be more focused on making sure the quality of the software is good.

But all are developers.

If you have a QA in your team that does no coding, your team may not have developed the necessary skills to assure quality of deliverables.

Answer 3

The ideal ratio is the one that best enables the team to successfully deliver a Product Increment at the end of the Sprint.

The Scrum Guide does not differentiate between types of developer, and only requires that the team has all the skills it requires to do the work. The specific mix will depend on what your Product is, and is likely to change over time, and the change could involve people moving in and out of the team, or it could involve people staying in the team but doing different parts of the work - for example, the people who are mainly doing testing could get involved in the coding, or someone who has been coding could help with business analysis to elicit user requirements.

This is something the Scrum Team can address at Retrospective - all it requires is to ask three questions:

1. What barriers are there to the team delivering its Product Increment?
2. Could any of those barriers be addressed by changing the skillset within the team?
3. How could we bring those missing skills into the team?

Answer 4

Some types of products and technology stacks lend themselves to test-driven development - in which case a few QA engineers can go a long way. Other products may require manual testing - for instance, software that runs on custom hardware needs full system testing via manual testers - and in those cases, you would need a healthy balance between developers and quality assurance engineers.

When the team starts to get beyond 10 people and they are really starting to crank out product releases, quality and reliability becomes important because the lack of these things will result in reputation risk and an erosion of trust by customers.