I am a developer by trait so I don't have a lot PM exposure. Due to circumstances I need to manage a small team which includes 4 developers and 2 QAs.

We are currently following loosely the "Agile Scrum" methodology with a 2 weeks sprint. By researching around, I see a scrum sprint includes planning, developing, QA testing and release but I am facing some difficulties with my QA resources planning in this model.

  1. What would our QA team member do during the development time of the sprint or in another word at the beginning of the sprint? The time when the feature is not available yet for the QA team to test?
  2. How do you handle a case where a user story of a sprint requires a large amount of regression tests by QA and they may not be able to complete them in one sprint? Even though the development time of that user story required is very little effort?

2 Answers 2


For the first point of your question, the answer is to not have the two activities (dev and QA) done sequentially. That's not Agile; that's one small Waterfall of duration equal to that of the sprint. This has already been discussed, so I won't go into more details. Please see What does a QA team do during the development phase of a sprint in Agile Scrum?

Regarding your second point, you really only have two options:

  • find a way to perform the tests faster (maybe another developer can work as a tester, find ways to automate things, etc). It really depends on how you work. If you do these tests manually, the answer is obvious: it doesn't really scale so try to automate as much as possible to be able to run them on one click of a button.

  • split the tests in two parts and do the second part in the next sprint. If you truly have no other way, then have a testing only story in your next sprint. If this is a one time occurrence then it's fine; s#it sometimes happen and you have to deal with it somehow. But if this happens often, then you have a problem: your "loosely Agile Scrum methodology" is broken and needs to be fixed. This is another thing already covered on the site. Please see Test only stories in the Sprint?

The short answer that covers both your points is: you need to have collaboration between developers and QA so that things aren't thrown over the fence from some to others and back, and you need automation testing to make sure things are tested before the sprint ends.

  • Thank you for your details answer @Bogdan, I'll read up on the resources you referenced and see what best practices I can get out of them. One thing that I read up on scrum sprint is the ability to produce a stable version of the application/product.... or at least one stable enough to be a candidate at the end of each sprint...that's why I lump QA in as part of the sprint work. Unless Agile in this case mean a stable product from a developer standpoint.
    – Fylix
    Sep 9, 2020 at 17:29
  • 2
    The product increment you get at the end of the sprint must be in an usable state from the user's point of view. That means it must be developed and tested. You need development and QA in the sprint, but dev+QA should be a collaboration, not a sequential process.
    – Bogdan
    Sep 9, 2020 at 17:34

This is one of the conceptual problems of Scrum which can't really be overcome. No matter how people are trying to sell the idea of Testing intertwining with the Development - Testing will always fall behind. You can work on shortening this lag (which is a very good thing by the way), but you can't eliminate it completely.

So you have choices like these:

  1. Follow Scrum to the letter and be inefficient by making both Testing & Development stall from time to time: at the beginning of the Sprint testing will stall, at the end of the Sprint development will stall (BTW it's fine if only Testers or only Developers are stalling, but not both).
  2. Smear some of the work across more than 1 sprint
  3. Have a shared pool of Testers across multiple teams. This allows for over-committing (similar to overcommitting CPU or RAM in a cloud) and maybe would allow testers to finish work within the sprint. Also violates Scrum, but in another way.

PS: please-please-please don't say Agile Scrum. These are orthogonal things. Even worse - in many aspects Scrum contradicts Agile. These days you have to be Agile, but Scrum is just one of the methodologies (far from the best).

  • thanks Stanislav, though it does not apply to our team because we are very small, I see the idea of sharing pool of tester across multiple teams is a great idea to combat this type of scenarios.
    – Fylix
    Sep 15, 2020 at 16:02

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.