Help me understand how QA works in Scrum [closed]

Question

Apparently we use the Scrum development methodology. Here's generally how it goes:

Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding. QA can never complete the tasks on time, sprints are rarely releasable on time, and Dev and QA have a miserable few days at the end of the sprint.

How is scrum supposed to work when releasable Dev tasks take up most of the sprint?

Thank you everyone for your part in the discussion. As it's a pretty open-ended question, it doesn't seem like there is one "answer" - there are many good suggestions below. I'll attempt to summarize some of my "take home" points and make some clarifications.

(BTW - Is this the best place to put this or should I have put it in an 'answer'?)

Points to ponder / act on:

• Need to ensure that developer tasks are as small (granular) as possible.
• Sprint length should be appropriately based on average task length (e.g. sprint with 1 week tasks should be at least 4 weeks long)
• Team (including QA) needs to work on becoming more accurate at estimating.
• Consider doing a separate QA sprint in parallel but off-set if that works best for the team
• Unit testing!

Answer 1

My opinion is that you have an estimation problem. It seems that the time to test each feature is missing, and only the building part is being considered when planning the sprint.

I'm not saying it is an easy problem to solve, because it is more common than anything. But things that could help are:

• Consider QA as members of the dev team, and include them in the sprint planning and estimating more closely.

• 'Releasable Dev tasks' should not take up most of the sprint. Complete working features should. Try to gather metrics about dev time vs QA time for each kind of task and use those metrics when estimating future sprints.

• You might need to review your backlog to see if you have very coarse grained features. Try to divide them in smaller tasks that could be easily estimated and tested.

In summary, it seems that your team hasn't found what its real velocity is because there are tasks that are not being considered when doing the estimation and planning for the sprint.

But in the end, estimation inaccuracy is a tough project management issue that you find in agile-based or waterfall-based projects. Good luck.