I've been reading up on Scrum recently. From my understanding, a meeting is held before the sprint starts, to decide what gets moved from the product backlog to the upcoming sprint backlog. Once a feature is completed in the current sprint, it will go into the "Ready to QA" bucket, and it's at this point that I'm getting confused. Do bug reports go back into the product backlog? I assume they can't go back into the sprint backlog as we've already decided what work will be done for this cycle? What happens when QA finds a bug? Where does it go?

  • 3
    Are your QA activities happening concurrently with and continuously throughout your sprint or do you have QA activities scheduled toward the end? Are these bug reports coming from a previous release or are they found in the middle of your sprint?
    – Thomas Owens
    Commented Dec 6, 2012 at 13:43
  • Ideally (project hasn't started yet), I imagine the bug reports will be reported during the current sprint, they'll go into our bug tracker, then we will work out which ones to fix. My current thoughts are that bugs will be fixed in the following sprint cycle (i.e. if bugs are reported in sprint 1, we can choose to fix them in sprint 2, if the backlog is clear). As I've never done agile / scrum before, I want to check whether this is sensible. Commented Dec 6, 2012 at 13:51
  • 1
    Beware of the bug reporting process becoming a political problem within your organization. If poorly integrated or constantly bypassed, it can disrupt Agile/Scrum processes, create morale problems within the team and lead to project failure.
    – jfrankcarr
    Commented Dec 6, 2012 at 17:01
  • 5
    Fixing a bug is a change. Implementing a feature is a change. There is no fundamental difference between the two: you estimate the effort, you have the changes prioritized, you schedule them into an iteration, you implement them. Whether you label them "bugs" or "features" isn't really all that relevant.
    – tdammers
    Commented Dec 6, 2012 at 21:51
  • When you say "bug reports", do you mean bug reports against the code you are developing in that sprint, or all bug reports for your product as a whole? Commented Dec 9, 2012 at 0:57

6 Answers 6


The way I see it there are two main solutions to this:

  1. Don't allocate 100% of your time to the current sprint. Allow 10-15% of your time for bug fixing and other support activities that will come up during the sprint. Then if a blocking bug comes up you have the time to fix it in the current sprint.

    If a non blocking bug comes up you can either fix it at the end of the current sprint if you have the time left over or it goes into the "pot" for the next sprint.

  2. Have a "bug fixing" sprint every so often. Probably just before the next major release. You can use this to "mop up" as many bugs as you can/want to fix for the next release.

Neither of these solutions is probably true to "pure" Scrum, but they work in the real world.

During a "regular" sprint you can still include tasks to fix specific bugs, treating them as you would a piece of new functionality.

  • I want to avoid having a specific sprint for bug fixing, as that seems to be closer to waterfall methodology, than agile. Commented Dec 6, 2012 at 16:00
  • @MarkIngram - Perhaps it does. In that case you need to have something like option 1. Explicitly schedule bug fixes as part of each sprint but allow slack to cope with blocking issues.
    – ChrisF
    Commented Dec 6, 2012 at 16:02
  • 1
    One way I've handled Option 1 is to set aside a block of points, in the backlog for bug fixing. It makes planning a little easier and gives visibility to priority etc. along with other work items. Of course you wouldn't include these "bug fixing points" in with your velocity since you're not adding any value...
    – Michael
    Commented Dec 7, 2012 at 16:08

In an ideal scrum world, there is no "Ready for QA" bucket (at least not visible outside the team), as a feature is not completed until the QA activities are finished and the bugs fixed. This means that there should be people in the team that can take on the QA activities.

In the real world, you might have a separate QA/test team that works in parallel with the scrum (development) team. In that case, the following approach might work well:

  1. Just before a feature is put in the "Ready for QA" bucket, the (main) developer of that feature and the QA representative who will (likely) take it over sit together and walk through the feature. Any issues found at that time are solved before the feature is put in the "Ready for QA" bucket. Note that this is not an early part of a sprint demo. It is meant to get the low hanging fruit in the issues solves as soon as possible.

  2. Any issues found after the handover to QA should be placed on the product backlog as stories, to be taken into account in the next planning meeting.

  3. For show-stopper bugs, reserve a fixed amount of time each sprint. If, near the end of the sprint, there is time left in this buffer, it could be filled with issues of lower priority.


Based on how you're describing your workflow from a story, with a product backlog, a sprint backlog, and other buckets (I'm assuming they look something like "in progress/in development", "ready for QA", "finished"), it sounds like you're adding some elements of Kanban to Scrum - a not uncommon combination sometimes called Scrumban. The notion of Kanban adds limits to the size of each bucket to prevent your developers from having too many stories in progress or your testers from testing too much. It's similar to velocity for moving items from your product backlog into your sprint backlog, but within a sprint.

I would approach the problem by having your tasks be the user stories, with your user stories moving from the product backlog to the sprint backlog to the in progress bucket to the ready for QA bucket to the finished bucket. After the developer finishes the story (based on your definition of finished), he would move it into the "ready for QA" bucket where the next person would pull it out and work on it. If there are any problems with it, a defect would be entered in your tracking system and the user story would be moved into the finished bucket since it's been implemented and tested. If there are no problems with it, it moves right into the finished bucket.

When the defect comes from within your sprint, there's no problem with putting it back into the sprint backlog (or perhaps some kind of "in progress" bucket). A story with known defects is usually considered to be unfinished. If it's determined that there's insufficient time to finish the story or the defects are attributed to not understanding the story, an option might be to descope it from the sprint entirely until you can better understand the need - in this case, I'd recommend not including the defective implementation in your released product.

If, due to your defect, the story doesn't get finished in your sprint, this will come out in your velocity calculations for future sprints. Unfinished stories (defective stories) don't get you any story points, so you'll plan for smaller sprints. Fewer complex stories will lead to more time in testing and will encourage you to spent more effort finding defects early - preventing defects is not only cheaper, but takes less time than the sum of the time spent to identify that a problem exists, find the problem in the design or implementation, fix the problem, and retest to ensure the problem has been solved without any other negative impacts on the system. Since the timebox is key, the ability to prevent defects leads to more productive sprints in the future.

Regardless of what you do, you should involve the Product Owner (who is hopefully a customer/user representative) when it comes to deciding how to prioritize defects. Some defects might be acceptable to be put into a release if there are workarounds or they are rare, meaning the defect would show up as a story in a future sprint. Other defects might be urgent and "showstoppers" - these must be addressed immediately and a product can't be used if they exist.


If the time spent on defect is fairly consistent from one spring to another, then you don't really need to manage it - your team velocity is going to reflect that.

Otherwise, if defects fixing can be planned (i.e. you can postpone fixing them for the duration of a sprint), then do so.

Otherwise, Scrum doesn't have a good answer - defects are going to be an unplanned sprint content change in the middle of a sprint, which means you'll need to renegociate your commitments.


A sprint should be self contained. That means all activities, including QA, bug fixing, and documentation, should be completed before the end of the sprint. Pre-deployment activities should also take place before the sprint is over.

The problem with not finishing is that you get distracted in the next sprint.

If, in sprint B, you have to turn your attention back to the code from sprint A so that you can fix bugs, then your ability to focus on the tasks in sprint B goes out the window. So does your forward velocity.


At my last job, sprints were scheduled based on the "ideal hours" concept; of an 8-hour developer-day, 5 hours were head-down TDDing new features that never existed before. The other three were doing everything else; e-mails, meetings, compiling/committing/updating code, refactoring work, and yes, bug fixes.

We considered a job that was done but had bugs to still count towards team velocity; however, bugs were technical debt that had to be paid off when it accrued, and therefore obviously to be avoided. We never had a real problem with people doing sloppy work; nobody wanted to have to backtrack.

Every now and again, we'd also have bug-fixing sprints. We had the dubious good fortune to have a client that couldn't deliver requirements at the pace we could consume them, so to let the backlog build up a bit, we often scheduled two weeks where the object was to "kill as many defects and pay off as much technical debt as you can". Technically, velocity for such a sprint is zero, but this is work that needs to be done and which makes the client happy, so it's worthwhile.

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.