2

Even if we make many small stories, we still end up splitting stories at the end of every Sprint because we cannot have Development under-utilized while QA is testing, and we cannot have QA being idle waiting for coding changes to test.

So there are always at least three stories (we have three developers) and two QA tests (two testers) unfinished at the end of the sprint.

How do others handle this issue? How do you keep your team continually working at top efficiency without splitting stories?

Improve this question
1
  • 1
    What is the problem in splitting some unfinished stories? I assume the team is able to finish more than three?
    – Tob
    Apr 2, 2015 at 20:30

2 Answers 2

Reset to default
4

Focus on maximizing throughput not utilization

If you are writing smaller stories that is good. Larger stories are difficult to estimate and are at higher risk of being incomplete at the end of the sprint.

However, I have three suggestions for you:

  1. Encourage testing and development to be done in parallel: The practice of completing development and throwing it over the wall for testing is a mini waterfall. Ask the developers and testers to collaborate throughout the development cycle. See the following links for additional explanation about how this can be accomplished:

  2. Encourage team members to be cross-functional: While team members will be strong in one area, once the Sprint starts they should pitch-in with whatever work is required to complete each story. When we tried this, people struggled initially but eventually were able to do more of it. And enjoyed doing so.

  3. Focus on maximizing throughput: The goal of Scrum is to deliver maximum value to the stakeholders, not keep all resources fully busy with make work. It is a faulty assumption that if you keep all resources busy you will somehow get maximum throughput. As someone pointed out the extreme case, if you utilize the roads to the maximum (filled with vehicles) the throughput goes down to zero (gridlock)! If the team finishes all the stories in the sprint before the sprint ends, let them enjoy the break. They will be more motivated to complete all of the work within the sprint.

Improve this answer
7
  • 2
    The idea of having QA in parallel with coding is good but not realistic in some environments, as it's hard to test something that's not completed yet. Unless you code one Story and then QA jumps in... which would fit the definition of mini waterfall you mentioned. All in all, my understanding is that code + QA will eventually be a kind of mini waterfall (as one activity can only be formally started once the predecessor is completed)... I don't see it working any other way.
    – Tiago Cardoso ♦
    Apr 3, 2015 at 0:15
  • 2
    True, QA cannot finish their testing prior to development being complete, but they likely can start before development is complete. Involving QA at the start of story means that they can be building out their test cases and scripts while development is ongoing. It also means making sure that developers and testers are talking about failure cases up front, so that the developers take those into account when writing the code. I've seen cases where developers will ask testers to do a quick informal ad-hoc review prior to development being complete. Some environments may prevent this, of course.
    – Kyle
    Apr 3, 2015 at 11:58
  • @Kyle Your comment is good, and should be fleshed out into a full answer. Embedding QA into the team's processes from the beginning of each iteration is certainly what I would recommend, too.
    – Todd A. Jacobs ♦
    Apr 4, 2015 at 17:41
  • @TiagoCardoso You neatly highlight the problem with having long stories in a sprint. Until the story is finished, it can't be tested. The tried-and-tested solution is to always decompose stories into tasks, of eg max 5 days. That way, testing can occur occur throughout the sprint as there's a rapid churn of testable tasks.
    – David Arno
    Apr 4, 2015 at 19:36
  • @TiagoCardoso Further, as Ashok says, there is huge benefit to having a tester work closely with a developer/development pair right from the start of an activity. There may be nothing to test, but such collaboration enables a tester's perspective to be applied to the planned work from the start, allows them to eg start planning a testing mind-map before the activity is complete and so forth.
    – David Arno
    Apr 4, 2015 at 19:55
2

I think the question to be asking is "Is QA testing the right things?"

The developer completes a small story, this is a bit of code that likely contributes to a larger feature. If your QA is testing this, then I would guess there isn't a lot of automation or continuous integration happening.

If you have a continuous integration development environment, then if the Dev checks code in and it has a bug, you'll probably know as soon as the build fails.

If you have automated regression testing, then once the Dev checks in his code, those tests run and will let you know if the new code broke any of the old stuff.

I'm not a QA expert, so while I know this isn't what QA should be doing, I'm not the best person to say what they should. I've learned from really good Agile QA folks and I would suggest going to Stickyminds.com or look up Lisa Crispin, who has literally written the book on agile testing.

Get QA to stop testing what can be automated and utilization will not be the issue.

Improve this answer

Your Answer

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

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