From our webinar last December with Greg Burns and Ron Ben Yosef from BlackLine on agile challenges that they’ve faced and how they got through them, there were several questions from the audience that we had no time to answer. We sat down with Ron and Greg and discussed the 3rd out of 6, the classic question of the recommended Developer-to-Tester Ratio.
Answer: There is no one right answer to this question. It depends! Overall the idea is to break the epics into user stories that allow you to create a potential shippable increment that will be deployed at the end of the sprint. Hence, it should be fully tested. Breaking user stories to “right” size is a skill that requires practice and learning. Usually, a team will tend to get the idea after 2-3 sprints. Also take into mind that for an agile team committed to a sprint, everyone should help to get all the sprint scope “done.” This means that developers can jump in and test (preferably not their own code) tickets as well. Ultimately the team should rally and share responsibilities when needed, and each organization will have to find their right balance. We typically use a developer-to-tester ratio of about 3:1. Again, however, this could change dramatically, depending on: the roles and responsibilities, skills of both developers and testers, amount of test automation, who is responsible for writing test automation (could be either developers or testers), and the stability and experience of the team in working together, amongst many other elements.
The ratio of developers to testers has been a recurring question for the last several decades. Past ratios where Waterfall was deployed, were up to even 1:1, but this was in an environment where roles were more separated and the software was ‘thrown over the wall’ to the testers. In an agile environment, even though the developer-to-tester ratio may be lower on the surface, the testing still has to get done. The question is who does it.
Look out for next week’s blog in which Greg and Ron cover the importance of agile acceptance criteria in planning.