I understand that in scrum developers do some QA, but in the last several sprints we've been doing almost nothing but QA.

We've brought this up to management, but they insist that that's how scrum works (and I know it's not!), and that it's temporary (which it doesn't seem to be, either).

Morale is low among the developers, and management is very sympathetic but very unhelpful. Just to be clear, we've communicated that we are not willing to go on like this.

How can we fix this, without actually quitting?

To answer comment questions:

  • We're QAing new use-cases that hadn't been thought of, and stuff other teams did. Also, the occasional scrap we do develop is required to undergo days and days of QA (including related QA documentation)

  • The product owner decides what goes into the sprint. We get to give an estimate how much will be done,

  • Clarifications regarding the amounts of QA we're doing: there hasn't been a lot of QA done before, and we're making up for it. What was done was pretty basic, and they're using us to do more thorough QA. Again, we're also doing QA for the little bit we do get to write, but each bit of development takes a lot of QA time because: A) There's a lot of mandatory documentation, B) Most of us are developers, C) We're highly demotivated.

  • 23
    If no one is doing any development work what are your team QAing? Jun 21, 2018 at 7:47
  • 4
    @combinatorics maybe they never qa'd anything before.
    – bharal
    Jun 21, 2018 at 8:06
  • 2
    Who is deciding what goes into the sprint?
    – Erik
    Jun 21, 2018 at 8:23
  • 3
    Can you explain what exactly you mean by 'QAing new use cases'? It sounds like you mean backlog refinement, which is a core part of Scrum, but it shouldn't take up all your time. It could also be that as a part of the switch to Scrum, management is trying to also implement Test Driven Development (TDD).
    – Cronax
    Jun 21, 2018 at 8:23
  • 4
    Is management having you do "waterfall in disguise" by having you spend lots of sprints documenting and planning before you actually start development?
    – DaveG
    Jun 21, 2018 at 10:56

4 Answers 4


Scrum has nothing to do with development, or qa, or anything like that. It's really just a philosophy to help create better estimates by improving visibility of progress, and also to foster stronger communication amongst team members.

Agile is exactly the same.

Your better bet would be to explain the opportunity cost - that developers (generally) cost more than dedicated qa. Even so, it might be that your development practices are shoddy and you are creating too much qa work, and this "developers moonlighting as qa" is doing two things

  1. getting you to solve the qa backlog
  2. ensuring you aren't adding to the qa backlog

I doubt it is a mr miyagi lesson or anything. You would be better, however, considering how to automate the qa, instead of complaining you don't like doing qa.

Given all you are doing all day is, in fact, qa, you should have a very good idea of what the steps are and how the qa process is. Work out how to automate (all? part of?) that, show that to management, build that tool. That's a good way to get a promotion by showing initiative, build something and stop doing QA.

Note you will still have to QA your qa-tool, so you won't be fully able to stop QA with this idea.

  • 2
    "Agile is exactly the same." Wrong, scrum is a subset of Agile.
    – Sandra K
    Jun 21, 2018 at 14:24
  • 1
    @SandraK Yes, agreed - Scrum is a way of implementing agile. I'm simply stating that the aims of the two - the high level aims - are the same.
    – bharal
    Jun 21, 2018 at 18:25

I'm guessing that something has happened to prompt a call for a far more rigourous QA system. Management don't really care who does this, but they want it done and done right, and they want to send the spreadsheets of results to people who care about these things.

Saying that QA is "part of scrum" doesn't really mean much and isn't really relevant here. The core of the problem is that there's more QA work that needs to be done.

As your team pretty much fully tasked with QA, all you can really do is carry it through and complete this task to the best of your ability. Putting your tools down and saying "We're doctors, not warp core technicians" won't really help the project right now.

Moving forwards, you either need to employ/resource a dedicated QA team, or build a more formalised QA stream into your development methodology.

Discuss this with your managers when the current test phase is complete and the panic is over. If this doesn't change over time, then management will need to deal with the ensuing attrition caused by people wanting to do the jobs that they were primarily employed to do.


An important aspect of Scrum is that the team work together to deliver a unit of work during a short period. Delivering a unit of work includes what ever is necessary to consider the work complete. This my be design, coding, deployment, quality assurance, etc. Everyone is responsible together for all aspects of the work.

Any part of the work should be carried out by the people capable of doing the work. That means that if there is quality assurance work to be done the developers should help unless they are also needed to do something else. This approach has a number of advantages. It puts an emphasis on delivering something useful. Any particular task such as coding is not important. Doing what every is necessary to complete the work is what is important. Secondly it breaks down the silos between different skill sets including software developers, quality assurance, operations, etc. Nobody gets to do their part without consideration for how it effects everyone else.

This is a more satisfying way to work for many people because instead of being soloed working on specific tasks you are given freedom within the team to self organize to delver a build thing.

If quality assurance work is talking up too much time not that you have moved to Scurm then you have identified an problem you always have had. You team should work on finding ways to perform quality assurance more effectively. This may be hiring changing the skill sets on the team to have more specific quality assurance skills or it may be having the software developers work on automated tests or code refactoring to improve the testability of the work.

If developers think they shouldn't be working on quality assurance tasks then working in an agile environment isn’t for them. They should be let go so that can work somewhere where they can code and let quality be someone else's problem.


As I mentioned in a comment to the original question, I think this is management's way of claiming to do Agile, while actually perpetuating Waterfall. In particular,

We're QAing new use-cases that hadn't been thought of

sounds a lot like spending months laying out the full product before starting coding.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .