When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline.

  • What should the developers do when this happens?
  • What's the right thing to do from a Scrum perspective?

9 Answers 9


They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles.

Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA.

Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it actually finds bugs), who is going to fix them and when? Clearly if QA is part of the development team, stories need to be "bug-free" before they are Done. On the other hand, realistically, this means that some development must happen necessarily after QA, but within the same sprint.

This is why I've often advocated pairing between QA and developers. A story should be developed and QA'ed at the same time. This can be achieved when there's coordination, and development introduces QA features in code (e.g. tests), which removes work from QA, and when QA codes automated features and avoids manual testing. In this way it's much easier to get everything done at the same time.

  • 3
    I agree. If you are running a true agile program, then developers need to take responsibility for their code. Test Automation and Continuous Integration can go a long way to help this. Commented Sep 10, 2014 at 20:18
  • 1
    I absolutely agree. See the discussion here re I vs T shaped resources scaledagileframework.com/continuous-delivery
    – gbh
    Commented Sep 24, 2014 at 16:35
  • 1
    Skilvvz is spot on. While certainly, some people will be focused on testing skills, Agile erodes those role classifications. You have to look at the best way for the team to work. If you are short handed on people who are good at determining what to test, then maybe that person works with other team members to develop the right test cases while the developers can spend the time actually building out and running the tests.
    – Daniel
    Commented Sep 26, 2014 at 18:34
  • If you swap the word "QA" for testing/testers, then I completely agree: developsense.com/blog/2010/05/…
    – David Arno
    Commented Dec 22, 2014 at 13:43

Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

Why is there too much QA work for your team to handle?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.


What's Wrong with Your Team's Processes

When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

  1. Your Product Owner should never, ever be assigning work to the team.
  2. Your "developers" and "QA people" are not on the same team, or not working closely enough together within the same team to meet Scrum's definition of a Development Team. A good Scrum team should contain all the skills needed to meet each Sprint Goal within the Definition of Done.
  3. Quality assurance doesn't sound like it's part of your Definition of Done.
  4. You have deadlines instead of iterations with potentially-shippable increments.
  5. The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
  6. Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
  7. A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

  1. Enforce the Scrum framework rigorously.
  2. Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
  3. Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
  4. Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
  5. Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
  6. Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!

  • 2
    It's rare I use the word but this is an outstanding analysis. Every day is a learning day and today I learned how experience can very quickly and authoritatively dismantle a dysfunctional environment. Commented Sep 11, 2014 at 17:57
  • I agree there are lots of good points in here, however I feel it may not be very useful for the OP at his current status. It's like someone asking for advice on how to bake a certain kind of bread, and you answer by pointing out how everything he is doing in his bakery is completely wrong. In my experience, very few people can handle this level and amount of criticism all at once, especially unsolicited. Which means your good advice will most likely be disregarded here. (Of course future readers - including even the future OP - may still find it useful...) Commented Sep 12, 2014 at 8:07

In my teams all developers would cross-check their developments/bugfixes:

  • Review their code using a GIT pull request,
  • Validate the behaviour by testing it in the browser,
  • Validate the functional behaviour too - if it's illogical, it's the role of the peer to go to the functional expert/PM and check the development still makes sense.

It's a great way to spread and exchange knowledge so both developers have knowledge on the ins and outs of the software. Since it's a peer review, all developers put their issues in QA at the same time of the sprint and test their colleagues' issues, so it doesn't add lag and it rather empowers them to discuss and fix issues.

In your situation, it seems QA hasn't been done during the development process and you're doing it altogether at the end of a cycle.


I don't know the specifics of agile, but having the same individual checking his/her own work is like having an inmate holding the keys to his cell.

The incentives are different. The QA / QC person is incented to find as many defects as possible while the builder of product is incented to boast what a great job was done first time around.

Now let's get to the human factors, the biases that affect ALL of us. We don't see what we don't want to see. If we think we did a great job building something, then we intuitively look for evidence that shows that and ignore, dismiss, minimize, justify the evidence that contradicts it.

If you have developers do their own QC, then you are essentially degrading the QC capability to the point where you could be better off cost wise to just deliver without it and go at risk. Conduct QC is expensive, paying for lousy work is very expensive. Delivering a product with defects is also expensive...but you didn't do anything to minimize that cost so you might as well just pay once.

  • 3
    David, your points are indeed valid, however a) developers doing QA does not mean that everyone is testing his/her own work - as most teams include at least 2 devs, they can trivially cross-check each other's changes; b) testing skills can be trained and improved. Agile approaches don't compromise on quality, on the contrary. They see high quality as a foremost enabler of rapid, repeatable, stable deliveries and ultimately, customer satisfaction. Commented Sep 10, 2014 at 12:02
  • You check my work and give me a passing grade, and I'll do the same for you. It is about incentives and work motivation. The QC folks should be completely independent with different rewards and incentive packages, different chain of command. It certainly helps to do a cross check but you will not be implementing the degree of QC performance, and results, without independence. Human factors, the things we cannot control, don't allow it. Commented Sep 10, 2014 at 12:05
  • 2
    If developers are doing this, the result will blow up at the next sprint review when they are expected to demonstrate to the Product Owner and possibly other stakeholders as well what they have completed during the sprint. Sprint reviews are due every 4 weeks at most, so feedback is rapid enough. This is btw a key point in agile. In traditional QC processes, feedback is slow, which is very costly in the long run. Commented Sep 10, 2014 at 12:11
  • 2
    There are differences between unit testing, acceptance testing, and approvals/sign-off. While agile processes typically include TDD/ATDD within each iteration, customer acceptance is also baked in as part of the Sprint Review, so this isn't as much of an issue as one might think.
    – Todd A. Jacobs
    Commented Sep 10, 2014 at 16:45
  • 1
    @DavidEspina - without being too blunt about it. If a Dev marks their own homework in such a way as to hide, obscure or deny good testing then they get fired fairly rapidly when the stakeholders are invited into Sprint Reviews to see a functioning product. The iterative nature keeps everyone honest since they have to demo every week, fortnight or 30 days. You built it, you own it (until the PO takes ownership). Commented Sep 11, 2014 at 17:53


I think that QA is completely different kind of work than development is, that it requires a completely different skillset, that it is repetitive and therefore quite annoying for a developer, and as such - I think - unnaceptable to be transfered to developers just becuse they are capable of doing it. Why is QA team never asked to do development? Why are DBA never asked to do development? Devs are on top of a pyramid and POs are taking advantage of this to fill in their organizational mistakes and miscalculations?


An agile team is a cross functional team. Their ultimate aim is to complete User stories committed for current sprint. Thus it is absolutely fine for developers to do QA when time permits and to meet deadline. However, the Product Owner asking for this change is against the rules. A product owner is there to define the product requirement, furnish details, clarify queries, participate in product demos, and in the end accept/reject a sprint. The Scrum master can make this decision to deploy the resources more efficiently.


First and foremost, the project manager should be setting the direction for the team and assigning work. Product Owners should not be doing this. It sounds like there is either no PM or there is one "in title only", and their influence is weak. You should seek to correct that situation first, so everyone understands their role on the team.

Agile team principles would say that developers should be able to help with QA. But I would add these qualifications:

  1. A developer should only do QA for someone else's development, not their own.
  2. It would be preferred for the more senior developers to do QA, not the junior members.
  3. If at all possible, a brief review of what was tested and the results should be held with a member of the QA group.

What should developers do and what is right within scrum: If you are truly following scrum you should find out what the priority of the request is, discuss the request and come to an agreement about what you will do and estimate it, commit to doing the things you agree to do and then follow through and get them done.

Some things to consider:

When talking about QA you are describing many possible things. For example, QA might be manual testing of the software in a production-like environment (we don't all get to do full CI/CD with 100% automated testing even if some of our peers are doing that). It might also mean something as close to the development effort itself as writing good unit tests. The place where programmers can work most effectively is nearer the code. We often do not feel as comfortable testing "the whole system" for any number of reasons. Those reasons might even include that we can get caught up in the process of trying to perfect the overall product when we should be focused on the change we are making. Sometimes this is a good thing and sometimes it is disastrous. Consider the case where you are a developer on a small team within an organization that has hundreds of developers working on a really large system for example. Getting your developers' hands dirty sounds like a good idea and might be, but it might also mean getting no code written during an iteration because they are spending time trying to reproduce scenarios they are unfamiliar with or configuring environments that they don't fully understand or even just trying to obtain needed credentials for parts of your system that they do not normally have access to.

Working closer to the implementation is a more likely success as far as good use of developer time. Your developers can easily (very possibly MOST easily) build automated tests of small units of the code. They understand the individual classes, functions or modules in your codebase and the details of how an individual part that they are working on SHOULD be well understood by them. Small-scale automated tests like unit tests probably don't require special permissions or access and should be something your build can include so that the smaller parts of the code are know to be high quality already. I would recommend that automated testing be something your developers work on from the inception of any enhancement to the codebase. They are useful even when fixing bugs.

I never want my developers working on manual testing of the UI or even running batch jobs manually for that matter. I certainly don't want them testing their own work if they are the "last line of defense" before the customer finds a problem. QA experts are much better at that and a good QA team member will be more focused on the right kinds of details and simple know how to build a good test plan and execute it. So in cases where we mean those kinds of testing it is my opinion that developers are a bad choice for the work.

We almost all take pride in producing high quality software but we should take advantage of the skills of different experts in ways that make sense. The scrum guidelines say you should have a cross functional team, but they do not generally say that a developer is a tester. They generally say that everyone on the team should be skilled enough to do any of the jobs that the team does. Maybe it would be better if you considered one of two obvious ways of composing a team to fit that description. You could either make all testers and developers the same (and require a person with the skill and interesting in doing all of it). You could also make two different teams, one that focuses on writing code and another team that makes sure the code works. The second option sounds "bad" to many managers but in the few cases where I have seen this done it works WAY better than the first option. I think of it like this: if you were building a car you would probably not have the same guy welding the frame together as the guy connecting the wiring or the guy doing painting. They all work together. If they don't the car sucks. It has nothing to do with throwing things over the wall because they are on different teams or not and everything to do with realizing that everyone on the line is building a car and if they do a bad job the car will suck. That also means they have to care about it. If your team doesn't care then no amount of togetherness or team building or co-location or open work areas will help you build a better car.

Final point: Even if they find some bugs and even if you manage to check the QA boxes, you still run the risk of losing a talented developer by pushing them into a manual QA position. I'm not saying I would ever quit a job for that but I will say this: I know many highly skilled developers who have left over just this issue and I know that my teams have regretted every one of those losses.

Your Answer

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

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