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.

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.