How do you plan a sprint with disproportionate Devs/QA members ratio?

Question

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.)

Answer 1

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.

Kanban

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.

Scrum

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:

1. Build an automated, test-first approach into the workflow so that QA stops being the bottleneck.
2. 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.
3. 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.
4. 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.

Other Considerations

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.

Answer 2

You don't want idle workers, but above all you should not want idle work, it's idle work what actually gets translated as the cost of delay (see related blog post).

The few past months I was able to solve this same thing for a start-up company.

These are the steps I took:

1. Accept that the done ratio is the speed the whole process goes on the features to production ready, so your fastest is the speed of delivery of your bottleneck.

2. As per @ToddAJacobs said, limit your WIP. I would add limit it to what your process bottleneck can deliver. Let me highlight that I do not mean the QC individual but the part of the process instead (as you'll see explained on 3.). Don't plan for more than your bottleneck can handle. Get the QC to estimate how much can he ideally take and devs should only take as much as the QC will be able to deliver. That should leave you a lot of idle workers, but work stops accumulating until you figure out how to solve your problem.

3. Get your idle workers to work in bringing proposals and after, to actively take action on mitigating the issue while the budget is being reviewed. Some of the actions we reviewed and agreed on pursuing were:

   • Getting the team to improve their quality by pair programming, and other quality procedures. Less bugs means less work for the overloaded QC process (among other good side effects in code coherence and maintenance).

   • Teams working in automate their related part of the QA's work, and regressions. Work getting easier for the QA means more time to take for story sign off.