Let's say you have five developers and one QA tester.

All 5 developers can commit to X number of user stories.

In Planning, QA decides he'll need Y number of hours per story to test.

What is the protocol or best practice when QA is has reached their confidence threshold within the sprint, but one or more developers haven't reached their full confidence threshold?

  • 4
    Could you describe more about how you are integrating QA with your developers? I read this as your QA would start the sprint with nothing to do, waiting for developers to finish the first stories. Then at the end of the sprint, QA would have a lot to do. Unless perhaps you are running your QA with a delayed sprint schedule? I'm more familiar with QA having a separate team rather than trying to integrate into the developer team.
    – mdfst13
    Commented Dec 11, 2020 at 12:24
  • Our QA team is divided across 3 other projects that aren't ran in tandem. If they are waiting for tickets to arrive in their QA column of the scrum board, they likely have work in another column in another project. Commented Dec 11, 2020 at 17:54
  • Your QA person is not a developer? How is that QA person ever going to write tests? I mean black box tests: perhaps. Integration tests: hardly. Unit tests? Forget it. I never understood this artificial divide some people seem to have in their mind regarding QA vs. developers. To me any QA person would have to be a best of breed developer to even qualify as a tester. Just my two cents. I've dealt with underqualified developers before and had to "babysit" them, but they were anyway just someone to point at in case of errors found by customers. Commented Dec 12, 2020 at 21:11

6 Answers 6


It seems to me that you are trying to fill each sprint to capacity, and keep everyone fully utilized. Planning for 100% resource utilization is a bad idea. You will only end up with busy people and delivery will suffer.

The point with Agile and Scrum is to deliver value. One QA tester to five developers can quickly turn into a bottleneck while work moves through stages within your sprint: "Development stage done, move to QA stage now. Ups, bottleneck".

Work within the sprint needs to be a collaboration of everyone to deliver value towards the sprint goal. If QA needs help to keep things moving, then the developers should help, by taking the QA role. The protocol, as you call it, is collaboration, not "I've done my job, things are stuck in QA, but I still have some capacity". The team should swarm on any impediments they encounter and keep the flow of work moving.

  • What does this mean in more concrete terms? Commented Dec 11, 2020 at 18:16
  • 3
    Developers learn how to do QA and actually test. This is the usual solution under the assumption developers are more skilled than QA and therefore can do QA's job at least as well. I've seen that disproved often. That said, there usually is enough of 'boring, mechanical' tests where developers can actually help that it isn't a problem.
    – ptyx
    Commented Dec 11, 2020 at 23:11
  • 1
    @user253751: It means that if a team member has difficulties in performing their work (for whatever reasons) the team should step in and help however they can. On the long term, it also means that the team needs to figure out a way to minimize this problem happening again. A long term solution might still be to help when needed, or for developers to do QA and share the load, increase automated tests to decrease the load on the tester, hire more testers, etc.
    – Bogdan
    Commented Dec 12, 2020 at 10:38
  • @Bogdan So in other words, it means nothing concrete, other than "find a way to stop this happening" Commented Dec 12, 2020 at 22:57
  • I agree that this is correct on the more occasional side. If developers are spending a significant amount is time on QA during most or all sprints, then that means you're understaffed on QA roles (and possibly overstaffed on developer roles) and your developers are probably not going to be very happy at all. Agile is not a (long-term) replacement for not having enough people in the right roles.
    – NotThatGuy
    Commented Dec 13, 2020 at 4:36

One possible approach you could consider is using the surplus developer time to create automated regression tests.

In the long-run this will give you better automated test coverage and will reduce your dependency on manual testing, helping to alleviate this kind of problem in the future.

  • 1
    This is surely close to the best route - unload and help QA while using developer time to produce value.
    – ti7
    Commented Dec 10, 2020 at 19:30

In Scrum, you should not see the distinction between "developer" and "QA tester". As of November 2020, the Scrum Guide says:

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

A Scrum Team has one Product Owner, one Scrum Master, and Developers. Developers include all of the skills necessary to create a usable product Increment every Sprint, which may or may not include various specialist roles. The team, as a whole, is cross-functional, but individuals also strive to be cross-functional. People should generally be able to contribute to other aspects of the work as well.

If time testing is the bottleneck, the QA tester should work with the developers to improve their testing ability. If the developers are working on testing, then the workload can be shared. There are lots of ways to help share the workload. Perhaps the developers write automated tests to reduce the likelihood of regressions, meaning the QA test specialist can focus on testing the new functionality and exploratory testing. Perhaps the developers learn manual testing techniques and can share the burden by testing each other's work. The team may have other ideas.

If the team has reached its limit for what it, as a whole, can get Done in the Sprint, use the opportunity to increase the skills of the team so there are more people to be able to take on a wider variety of work and the team's capacity, as a whole, will increase.

  • 1
    while I agree with you, and indeed it's specified as such in the Scrum guide, it would basically mean we only hire people with a developer profile then... I wouldn't want a tester to touch the code base too much if workload was the other way around. I can totally relate to the bottleneck effect, but the only way I ever was able to really solve it was to change a bit the composition of the team... I think testing requires a different skillset than development, while some overlap is always suitable, but not always reachable.
    – Laurent S.
    Commented Dec 10, 2020 at 14:19
  • 2
    @LaurentS. I do think that it's important to have test specialists. However, in the situation described, there are two solutions, but they aren't mutually exclusive. The first step is to train developers in some aspects of testing to reduce the pressure on the test specialists. If that's still insufficient, then you may need to hire more test specialists. Even with cross-training a 5:1 developer:tester ratio is probably not sufficient, but you'll have a better idea of what the ratio is after cross-training the developers.
    – Thomas Owens
    Commented Dec 10, 2020 at 14:58
  • 4
    @LaurentS. I've never seen a situation where "writing the code" was the bottleneck. Testers can help developers tons without actually being the ones committing the code directly.
    – Erik
    Commented Dec 10, 2020 at 16:25
  • The term "developer" doesn't mean "people who code" in scrum, but "people who make the product" - when I've been a content manager in a scrum team, I was part of the development team. The scrum guide needs to replace the term "developer" and maybe "development team" with something that better describes what the proposed reality is (maybe "producer" and "production team"?) The team needs all the skillsets necessary to produce finished product. At the moment they're missing enough of a skill. How does that get plugged to help produce finished product?
    – Karl Brown
    Commented May 31, 2022 at 11:26

Best practice is the team decides what they want to do.

Personally, I'd see if a developer could help the tester, so the tester gets a little bit more done and the developer is not idle. Bonus effect: at some point the tester will be away on holidays or out sick and some of the developers know how to stand in for them.


In my experience... developers and testers are on the same team.

If dev gets all of their work done, they swarm with QA on getting stuff tested. As a team we sink or swim together.

  • I think the OP was asking the other way around. What do QAs do if QA is done but development isn't?
    – Sarov
    Commented Dec 11, 2020 at 22:15
  • The principle is the same. QA folk can help the devs in all sorts of ways: shadowing code development and picking up obvious errors, doing comms, admin, making coffee, attending status meetings, being a "rubber duck", etc.
    – Kramii
    Commented Dec 12, 2020 at 18:05
  • The OP reads as "What if QA has reached their confidence threshhold but dev hasn't?" That means QA has committed to as much as they're confident they can handle, but dev still has hours to add. But yes, I have never seen anything where QA or dev is just twiddling their thumbs... there's always something that can be done, and the best QA people I've been around have spent "free time" poking at the code or the application to try to gain an even better innate understanding... if they aren't working on automated tests.
    – Bardicer
    Commented Dec 15, 2020 at 16:29

First and foremost I feel the estimation process is not complete or the definition of done for a story is not defined appropriately. A story is generally completed, only when it has been developed, tested, and merged(released) into the pipeline, so the estimation of story points is Dev + QA effort. If you are separating the effort, you are not following the true DevOps(Agile) and will end up chasing the dev effort and as code cannot be merged without testing completed, it will lead to delayed delivery and hard to manage the dependencies Bla bla bla.

Also, the most important thing of Agile is a stable team (not stable resource), the team need to work in conjunction with each other to achieve success ( if dev and QA are working on there own, why Agile, better do waterfall), Developers can help in developing more unit test cases to increase coverage or help in automation by extending the framework, so QA can take less time to complete testing a particular story, also one more point is if you for sure know as you mentioned 5 dev to 1 QA is not an appropriate ratio in the very first place, so as a scrum master, you need to balance the team to achieve optimal/high velocity.

Reach out to the functional manager for having the right resource balance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.