So what is the right ratio between developers and testers?
Developer-to-tester ratios are less important than flow — why Kanban thinking shifts the focus from headcount balance to constraint identification and queue management.
One of the questions I’m asked quite frequently is what is the right ratio between developers and testers.
A variant on that question is what I typically see in other organizations as the ratio.
Well lets answer the second variant and then try to deal with the first.
Typical dev-to-test ratios
Typically what we see in agilesparks customers is 2:1 or 3:1. There are some exceptions of 3:2 or 5:1 but they are quite rare.
What is right? Well as u might expect it depends: - what are the skills/strength of developers and testers. Not all engineers are made equal… - how are the responsibilities spread between roles? Eg test automation etc. - what is the development life cycle style used by the group - what is the quality of the code when delivered to testers - technology and character of the system. Usually the lower the product is in the stack the more testing it needs per code developed. This is due to the amount of impacted areas, the complexity to test, and the breadth of the configuration/platform matrix. - how much test automation exists
The waterfall testing squeeze
One of the typical dynamics of a phased waterfall-like development lifecycle is that QA phase starts late and pressured and compromises in quality are part of life
This means very tough weeks/months for the poor testers which get a big blob of code to work on, they are outnumbered, usually outskilled and the following happens: - the perception is that test is the bottleneck. ( well I would say that in waterfall each phase is a bottleneck. Those that tend to be the last ones just get the short end of the straw ;-) - either test phase is prolonged or developers are asked to help do testing. Or both.
But what also happens is that organizations get used to this. It’s a fact of life. For some reason the need to strengthen the test organization is usually outweighed by ability to develop more features each version.
Another thing is that developers do end up helping testers they usually do it in crisis mode when their only option is to help do the work, not help testers have an easier job the next time
What changes under kanban
Lets see what happens when such an organization moves to agile/kanban
In kanban or any kind of lifecycle that is feature driven developers and testers are expected to have more Or less the same pace / feature velocity. So our typical outskilled outnumbered testers usually quickly appear as a bottleneck early in the transition to agile.
Limiting the WIP in test and Dev causes Dev to stall, leading to one of the classic discussions in kanban workshops and even some kanban games I wouldn’t mention to avoid spoiling the fun ( Carlos - we know you’re out there!)
In an upcoming post I will try to cover what can be done when this typical scenario happens, using practices from Agile Testing, the TOC five focusing steps, and agile engineering practices I general.
Finding the right agile ratio
Moving from agile theater to real business agility takes more than a framework. Explore Business Agility advisory or let’s talk.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →