How do you plan a sprint with disproportionate Devs/QA members ratio?
morde last edited by
How do we plan a sprint in which we have 5 developers constantly coding and only 1 QA to test the output? Basically QA ends up to be the bottleneck in every sprint. One option is hire more Was but until that is in place, what are strategies can we have in place? (General agile principles say team members should be somehow interchangeable, however this is not always possible.)
Demir last edited by
Introduction: Focus on Right-Sizing Your WIP
A lot depends on your framework. As you simply tagged your question agile, it’s almost impossible to give you a universal answer. Nevertheless, controlling work-in-progress (WIP) will likely be key.
In Kanban, you would typically reduce your WIP for other work states (e.g. development) in order to control the size of the queue waiting for QA. Queuing up large amounts of work in a pseudo-state like “dev complete” or “ready for QA” simply hides the problem, and Little’s Law says that the arrival rate has a significant impact on how quickly items can be serviced or how long they remain enqueued.
In Scrum, it’s true that teams should be cross-functional. When they aren’t, you end up with bottlenecks like the one you describe. However, in Scrum a backlog item is always either done or not-done. It can’t be “partly done,” so work that is developed but not tested—and more importantly, not fully complete per your Definition of Done—is simply incomplete at the end of the Sprint.
Because development and testing are (or should be) collaborative activities within an agile context, development work can’t really be called done until it passes all regression tests, acceptance criteria, or refined to meet the objectives of the Sprint Goal. In such cases, the team should generally:
- Build an automated, test-first approach into the workflow so that QA stops being the bottleneck.
- Pitch in on QA tasks as needed, so that the team is focused on completing backlog items as they are developed, rather than simply keeping everyone busy or enqueuing work. NB: In Scrum, it’s often better for the whole team to swarm over a backlog item or user story rather than queue up work.
- Train the team members to be more cross-functional. This isn’t a quickl solution, but it’s usually the right one over the long term.
- Hire more I-shaped people to perform testing. This doesn’t really solve for the process problem you’re describing, but it should address the specific resource constraint you’ve defined.
Most agile frameworks focus on throughput rather than utilization. INVEST criteria, WIP limits, swarming, and small batch sizes are all simply techniques to help the team complete work per the Definition of Done rather than focusing on maximizing team-member utilization. This generally results in better incremental progress, even when management targets, delivery dates, or Sprint Goals aren’t always reached.
In my professional experience, reliably getting N work items to “done” is often a better predictor of project success than getting X% of jobs to Y% complete (without actually being completely done). Engage the entire team on finding approaches to improve throughout and cycle time (in Kanban), or Sprint Goal completion percentages (for Scrum), and you will generally find greater success and more opportunities for continuous improvement.