Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Bug Only Sprint?

Last post 06:20 pm October 20, 2022 by Sam Hoffmann
5 replies
08:34 pm October 19, 2022

The project I work in currently has about 50 reported bug tickets. The current workflow is to maybe do a bug ticket or two after completing the stories brought into the sprint. Every couple sprints the product owner adds a couple high priority bugs to the current sprint, but for the most part, they just add stories. 

I really don't like this bug overhead. I work extra hard to solve as many bugs as I can while accomplishing the stories as well. I really want to get the project to a state where all bugs are addressed before the next release. (we release on a bi-monthly basis) To get to this, I really believe that one, maybe two bug only sprints could get our team to that state. 

Are there are formal processes for a bug only sprint? Obviously it would be good to have no bugs in the project, but I'm falling short of definitive arguments as to why we need to get to this state. Has anyone else had a bug only sprint? Has anyone had success making such an argument to the product owner? 


06:15 am October 20, 2022

Are there are formal processes for a bug only sprint?

It's work which remains to be Done, and which therefore ought to be accounted for on the Product Backlog. There's nothing to stop a team from having a Sprint Goal in which work of that type is mitigated.

Obviously it would be good to have no bugs in the project, but I'm falling short of definitive arguments as to why we need to get to this state.

Defects don't happen through chance or misfortune -- they arise because the Definition of Done is ineffective.

The Developers are accountable for ensuring that work is of Done and usable quality. I'd suggest that there is no argument to be made: this is a matter of professional accountability.

What is the team doing to improve the DoD, so when the Developers meet it each Sprint "bugs" are not introduced?

Has anyone else had a bug only sprint? Has anyone had success making such an argument to the product owner? 

The Product Owner is not accountable for quality, the Developers are, and the PO ought to respect this without argument. The Developers for their part ought to plan enough time into each Sprint to assure that a Done standard of quality is met. Their remaining capacity for planning in new work will reflect this commitment.


12:30 pm October 20, 2022

The Product Owner is accountable for "maximizing the value of the product resulting from the work of the Scrum Team". Focusing exclusively on bug fixes may or may not be the best use of the Scrum Team's time and energy, with respect to maximizing the value delivered in each Sprint.

You don't need to resolve the 50 reported and open bug reports to get to a state where all identified bugs are resolved before the next release. You can do this by working with the team to enhance the Definition of Done. Since the Definition of Done is "a formal description of the state of the Increment when it meets the quality measures required for the product", you can make a statement that a quality measure is "no known newly introduced defects exist in the product Increment". Some teams call this a zero-bug policy. However, it goes back to maximizing value - there are some bugs that are so rare, so easy to work around, or have such minor impact that the cost of fixing them often doesn't outweigh the value of delivering some other piece of functionality.

It would be a good use of a Sprint Retrospective to spend some time talking about how to prevent the release of Increments that contain new defects and how the Product Owner considers the value of fixing a defect. Value is not just to external stakeholders, but to the Scrum Team as well, so there could be opportunities for the developers to express the value in fixing a defect for consideration.


02:29 pm October 20, 2022

Everything that @Ian and @Thomas said echos my opinions.  You are in this position because the Developers are focusing on finishing stories instead of delivering quality. 

I'm going to share a Product Backlog management technique that has served my teams well if they ever find themselves in this position.  The Scrum Guide defines Product Backlog Items.  It does not distinguish in types of items.  Just a list of items.  So I suggest that you stop viewing things as bugs, features, stories, tasks, etc.  Just see everything as a piece of work that has to be done in order to improve the product.  I even go as far as to quit using the different item types you have in the software you are using to track these things and just make everything the same type.  To justify this I explain that everything in the Product Backlog has 2 values.  Negative value as long as it is in the backlog, positive value when it is in an increment.  This holds true for features or bugs.  The idea is that the team should be adding as much value to the product as possible.  Take a group of items from the Product Backlog into a Sprint Backlog that will support the Developers in reaching the Sprint Goal.  And the Sprint Goal should be stated in the value that is being incorporated into the increment.  Not something like "Finish feature A" or "Fix these 12 bugs".  What value is added to the product when the selected items are turned into positive value? 


04:13 pm October 20, 2022

There is nothing like "Bug Only Sprint". As Daniel mentioned, bugs are just items to work on the particular Spring. Scrum team decides the items for the Sprint based on the Velocity (a measure of the amount of work a Team can tackle during a single Sprint). I had some Sprints in past where we handle only the bugs as we had to deliver the releases with resolving the bugs. So, this is not an un-usual scenario.


05:46 pm October 20, 2022

I really appreciate all of the feedback provided here. I've been getting some feedback from my fellow developers on the team that they wouldn't love a bug only sprint and I can respect that sentiment. I'm going to propose the following two ideas to my team during the next sprint retro:

1) Every sprint planning has at least 2 bugs brought in from the start. Like which two are the Product Owner's highest priority. I think this will provide valuable input from the Product Owner on which bugs they believe would provide the highest value to the project at the time. 

2) We have weekly backlog grooming time. Usually we simply talk about any new bugs adding simple comments on them. The typical time is very inefficient with a lot of casual conversations. Sometimes we actually go into the ticket further, debugging or team programming the solution. I am going to suggest that we always maximize that time by reviewing all the new bugs, and then collectively working on one or two. I suspect this will have additional benefits by creating an opportunity for team members to learning from others project knowledge and development styles. 

Thank you again for the feedback and additional perspectives on this idea!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.