QA resource allocation in scrum sprint

Question

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?

Answer 1

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.

Answer 2

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