Help me understand how QA works in Scrum [closed]

Answer 1

Hopefully, you fix this by tackling fewer dev tasks in each sprint. Which leads to the questions: Who's settings dev's goals? Why is Dev falling short of those goals consistently?

If dev isn't setting their own goals, that's why they're always late. And that isn't the ideal way to practice Scrum. That's just incremental development with big, deadline-driven deliverables and no actual stake-holder responsibility on the part of developers.

If dev can't set their own goals because they don't know enough, then they have to be more involved up front.

Scrum depends on four basic principles, outlined in the Agile Manifesto.

1. Interactions matter -- that means dev, QA, project management, and end users need to talk more and talk with each other. Software is a process of encoding knowledge in the arcane language of computers. To encode the knowledge, the developers must have the knowledge. [Why do you think we call it "code"?] Scrum is not a "write spec - throw over transom" methodology. It's ANTI-"write spec - throw over transom"

2. Working Software matters -- that means that each piece dev bites off has to lead to a working release. Not a set of bug fixes for QA to wrestle with, but working software.

3. Customer Collaboration -- that means dev has to work with business analysts, end users, business owners, everyone who can help them understand what they're building. The deadlines don't matter as much as the next thing handed over to the customer. If the customer needs X, that's the highest priority thing for everyone to do. If the project plan says build Y, that's a load of malarkey.

4. Responding to Change -- that means that customers can rearrange the priorities of the following sprints. They can't rearrange the sprint in process (that's crazy) but all the following sprints are candidates for changing priorities.

If the customer drives, then the deadlines become less artificial "project milestones" and more "we need X first, then Y, and this thing in section Z, we don't need that any more. Now that we have W, Z is redundant."

Answer 2

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

As you've found out - it doesn't work terribly well :-) The process you're describing doesn't sound much like Scrum to me - or at least not like Scrum done well.

I'm unsure from what you've described whether the QA folk are part of the team - or a separate group.

If they're a separate group then this is probably a big part of the problem. They won't be involved in the team's commitment to completion of tasks - and the associated scope negotiation with the product owner. I've never seen an agile group succeed well without their being QA skills in the team. Either by having developers with a lot of testing/QA skills - or by having an embedded QA person or three on the team.

If they are on the team then they need to get their voice heard more in the initial sprint planning. By now it should be clear to the product owner and team that you're overcommitting.

I'd try a few things if it were me:

• Get QA/testing folk on the team if they're not there already
• Have a good long chat with the product owner & the team over what counts as "done". It sounds like some of the developers are still in the pre-scrum mindset of "handed over to QA"" == done.
• Break down the stories into smaller chunks - makes it easier to spot estimation mistakes
• Consider running shorter sprints - because little and more often is easier to track and learn from.

You might also find these tips about smoothing down a scrum burndown useful.

Answer 3

I think that there are several problems here. First, I think that perhaps the developer tasks aren't either fine grained enough, or perhaps not estimated well, or perhaps both. The whole purpose of the sprints in Scrum is to be able to demonstrate workable code at the end of the sprints. Both of the problems that I mentioned could lead to buggy code.

If developers are release buggy code towards the end of the sprint, I would also look at:

• Are the product owners really holding the dev members accountable for getting their tasks done. That's the job of the PO and if that's not happening, then the developers will slack.
• Are the devs using any kind of TDD. If not, that might help matters greatly. Get the developers in the habit of testing their code. We have this problem where I work, and my team is focused on doing the TDD in the important areas so that we don't have to have someone else do it later
• Are the task/user stories too generic? Wiggle room in the task breakdowns will cause developers to be sloppy. Again, this is somewhat of a PO problem.

One idea that I've heard batted around in the past is to use a QA person as scrummaster. They will be present for the daily standups and can get sense of where things are at with the developers. They can address issues with the PO (assuming that the PO can adequately do their job).

I can't help but feel that you need more coorporation between QA and your scrum teams. It sounds like testing only happens at the end, which is a problem. Getting QA to be a part of the team will help identify things that can be tested earlier and better.

I also feel like you have an issue with the product owner. They must be in there making sure that everyone is driving the right direction. they should be making sure that there is good cooperation, not only between QA and devs, but between the devs themselves.

Answer 4

One idea to consider is to have QA work one iteration behind the main development. That works well in our environment.

Answer 5

The Scrum rules say that all Sprint items need to be "fully tested, potentially implementable features" at the end of the Sprint to be considered complete. Sprints ALWAYS end on time, and the Team doesn't get credit and isn't allowed to present anything at the Sprint review that isn't complete - and that includes QA.

Technically, that's all you should need. A Team commits to a certain amount of work, finally gets it to QA two days before the end of the Sprint and the QA isn't done in time. So the output from the Sprint is zero, they have to go in front of the Customer and admit that they have nothing to show for a month of work.

Next time round, you'll bet that they'll pick less work and figure out how to get it to QA so that it can be finished on time.

Answer 6

Sounds like your development team might not be doing enough testing on their own, before the release to QA. If all your unit tests are passing, the QA cycle should be relatively smooth sailing, no? They'll find some integration errors, but there shouldn't be very many of those, right?