In our project we work in a zero-bug (a.k.a zero-defect) methodology. The basic idea is that bugs are always higher in priority than features. If you're working on a story and it has a bug it must be resolved in order for the story to get accepted. If a bug is found during the sprint for an older story we need to put it next on our backlog and resolve it - top priority.

The reason I'm saying resolve is that we not always fix the bug. Sometime we just declare it "won't fix" as it's not that important. All-in-all it sounds great. We're shipping high-quality products and don't carry "a hump" in the form of a huge bug backlog.

But i'm not sure this approach is correct. I do tend to agree that we always need to fix serious bugs ASAP and we need to throw-away non-interesting bugs. But what about bugs that are important but not as important as new features? I tend to think they should be filed in the backlog with a suitable priority.

I'll give an example in order for it to be clearer - in my project we work with a UI written in flex. We have a wizard screen that opens at the same size for every screen resolution. It turns out that when we extend the wizard window, one of the pages does not look good (there is a vertical scroll bar that does not disappear although the wizard can now present everything and does not require the scrollbar). I think this bug is ugly. I'm sure it MUST be fixed. But we're on a tight schedule and we have a lot of features that we're afraid won't make the cut and enter the release. I feel that we can live with such bug. It does need to be fixed but on lower priority than other features (so, in case we won't be able to complete it, at least we didn't leave out more important features). But, we work in a 0-bug policy and it must be fixed now (even though we spent more than a day trying to resolve it and we'll need at lease another one).

I would love to hear opinions about how to manage with bugs that I don't want to mark as "won't fix" but also are not of highest importance.

  • 2
    I know this is just an example, but getting rid of an unecessary scrollbar is a feature. Now if you attempt to implement this feature and and it doesn't work, you've got a bug.
    – JeffO
    Commented May 19, 2013 at 12:11
  • You should be willing to entertain the idea that your bugs-are-always-highest-priority way of doing things might not be the right thing for your needs.
    – Blrfl
    Commented May 19, 2013 at 12:17
  • @JeffO - I guess you're agreeing with me in a way. You just call it a story instead of calling it a bug. Which is indeed fine by me for this case.
    – Avi
    Commented May 19, 2013 at 12:23
  • 3
    There's a vast difference between "sounds appealing and correct" and "gets things done that keep the people who use your product happy." If 0-bug is demonstrably keeping you from achieving the latter, it's the wrong thing. I'm sure your management will adore having the extra time to brag about its methodology after your customers have found someone else to provide what they need.
    – Blrfl
    Commented May 19, 2013 at 13:18
  • 1
    @Avi - Seems like thats a feature that should be completed so your current agile approach does not delay new versions in the future.
    – Ramhound
    Commented May 20, 2013 at 11:31

6 Answers 6


Fixing bugs before writing new code is actually one of the twelve points of Joel test. Joel also explains why this is a must-have:

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.

You have a choice:

  • Either you implement a highly requested feature and delay fixing a bug, which will inevitably increase the cost of fixing it,

  • Or you fix the bug right now, given that customers will be disappointed that you're so slow at delivering the feature they need so much.

If the bug is not very important, while the feature is, management will be inclined to ask to implement the feature first, then fix the bug. Business-wise, this is a perfectly valid choice, as far as the management clearly understands the consequences, i.e. that it would be more difficult to fix the bug later than now.

Sticking to "no new features until all bugs are fixed" may not be the best business choice. You already mentioned its limitations, so there is no need to explain it.

This being said, the risk of letting very important features be implemented before fixing minor bugs has a risk: where to put the limits? Is a feature requested by 1 000 customers is more important than a bug encountered by 100 customers? How to evaluate whether a given feature should be done before fixing a given bug?

Without strict rules and if management doesn't understand the development process very well, you may see yourself in a few years with a backlog full of bugs which were considered not important enough in order to be fixed before just another fancy feature.

  • +1 The Joel test came to mind as soon as I read the title!
    – jkoreska
    Commented May 20, 2013 at 13:39
  • 1
    An addendum should be that there are lower impact ways to "handle" bugs. If you have a robust scrum which is good at managing bugs, then perhaps declaring that a bug will be delayed a little is acceptable... so long as your team is good at actually fixing the bugs they promise to fix later. If bugs start piling up, then that methodology has failed, and you have to return to a draconian "always fix all bugs first."
    – Cort Ammon
    Commented Feb 27, 2014 at 4:02
  • I think an important thing to add is to consider how long that bug fix. The bug the OP mentioned sounds like a fairly simple fix, so will it really make the feature late? If the answer is no, then just fix it. If the answer is yes, then perhaps it is more complex. I always though of this part of the Joel test as if its easy fix it. If it is complex, fix it because you don't want to leave complex tasks for too long due to forgetting how stuff works and regression.
    – MikeS159
    Commented Nov 13, 2018 at 12:27

Besides diving into particular low level details of your situation, you better make sure that you got the basic, fundamental stuff right.

In this regard, I believe it is very important to point out that the policy you mention, "bugs are always higher in priority than features", particularly the word always deviates from at least two of four principles stated in Agile Manifesto:

Individuals and interactions over processes and tools

Responding to change over following a plan

I do not insist that you should change policy, because I firmly believe that one should be agile about very application of agile principles.

But you should be at least aware when you deviate and understand whether and how deviation is justified. Simply put, you better make sure that what you call "agile", doesn't actually slide into senseless fake, so eloquently covered in Half-Arsed Agile Manifesto:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation
as long as that software is comprehensively documented

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

For the sake of comlpeteness, it's not only agile principles that zero-bug policy seem to deviate from.

In non-agile projects I participated, it has been generally considered er... unwise to spend programmers time on fixing bugs that are not important enough to justify delaying release of high priority features.

Because of that, management typically spent (maybe it would be more accurate to say invested) some efforts into deciding what bugs could wait to next release.

  • Do you by chance work on mission critical software? I ask because in this case, zero bug policy makes pretty good sense and is worth compromizing agile / non-agile / whatever principles. Though I have hard time trying to imagine agile process in this case.

You know, unless you work on mission critical software, I would recommend to more closely assess skills and thinking abilities of your management.

I mean, from what you describe, it rather looks that they are simply uncapapable to properly prioritize bugs and features. If this is the case, if they can't handle such a relatively routine task, what else are they not capable of? Providing competitive salary? career growth opportunities? working conditions?

  • 1
    +1 - I very liked the way you put it. Although it's not exactly a solution, but it justifies how I feel when I really support this method but believe that in agile everything should be negotiable.
    – Avi
    Commented May 19, 2013 at 20:34

As you rightfully indicate, a zero-bug policy has the risk that non-critical issues get ignored or shoved under the rug, because now is not the best time to solve them.

What you could do is, when a new issue gets reported, make a three-way decision:

  1. It's a genuine bug and should be fixed asap: put on top of the backlog
  2. It's a genuine bug, but is not critical to the functioning of the application: turn it into a regular story and let the product owner prioritize it.
  3. It's not a bug, or it's a duplicate or it's not worth the effort to solve: reject with appropriate reason.

This way, the less important issues will not be entirely forgotten, but they are also not forcing all the new shiny features out of the next sprint. The 'turn it into a story' is just so that management can continue to claim you are following a zero-bug policy and the product owner should be able to balance the importance of the issue against the importance of the features on the backlog.

Note that, with this procedure, issues like the scrollbar you mentioned might still end up being unsolved at the end of the project, but then it was because nobody thought it to be important enough (including the customers), not because there wasn't time when the issue was found.

  • 2
    Yep, though you do have to ensure that prioritization is done on proper grounds (business value) and does not use the "origin" (feature request versus test report versus bug reported from the field) as a "sorting" criterium where feature requests always come before ... Commented May 19, 2013 at 18:08

I like you scheme, however, as you have identified, it needs just a minor tweak to make it work - As you have observed, the reality is often a new feature trumps a bug fix.....

My suggestion is to force the bug priority increase each sprint. Lets say you have a bug at level 5 (scale 1-high, 5=low). It starts out as 5, 4 sprints later, its a level 1 bug. However, the mind set needed for priority calculation is "Current priority - Number of Sprints", rather than "Increase the priority of outstanding bugs at end of each sprint" - this prevents the priority being "reset" to low to defer it further.

Level 1 bugs must be addressed in the next sprint......

Is simple to explain, easy to implement....

Now, extent that to feature requests, maybe a different rate. After a while, the request must be dealt with - either done or discarded, preventing a backlog of features that have no value......

  • That's a great idea! I will bring it to my team for discussion! I think it still needs some more enhancements which I will try to think of. But I love the basic idea.
    – Avi
    Commented May 19, 2013 at 21:51
  • Ok, so after we discussed it we realized it may bring us to the exact same place in which a lot of bugs turn to level 1 :/
    – Avi
    Commented May 21, 2013 at 11:12
  • That's the point - if you're keeping unfixed bugs long enough that they pile up at the top of the workload, you're not following your rules. You're just accumulating technical debt. Commented Jan 23, 2016 at 3:06

You get into trouble when you try to be too literal or adamant about anything in software development as much as we all really want things to be cut and dry. Bugs should get fixed before new features are added, but I would still consider the importance of each when making this decision along with the scope of the problem. There are exceptions to everything.

Some applications are so large they have sections that are not related at all. I don't see why every new feature of the accounts payable module have to be put on hold, because there a couple of annoying bugs in the employee benefits GUI. If some wizard step GUI annoyance was located in the purchasing section of the company website, fix it, but many bugs may have to go unfixed if the added feature is a result of an additional security, business need, and especially changes in regulations.

Other than a large discrepancy in the time and resources to complete either one, it's best to get some user/customer input. If they can live with the bug if it means getting the new feature, add the feature. The goal should be to avoid letting bugs pile up, so have a stop gap. At some point many little problems become a major one.


Writing tests to show the bug when running the test is a good start to fix the bugs. But when trying to fix the bugs that has the least-of-all priority then we should think twice before proceeding with it. I did not mean to skip fixing it. But we can use non-critical resources to fix those bugs. Say, in my team, we train the new resources with the least prioritized bugs in the bug-list. By this way, we get a chance to train the new resource as well as impart a tint of confidence in them that they have made a fix in their entry to the application. This will certainly make them volunteer for the next prioritized task.

Hope this helps :)

  • Down-Voters: Did I miss something? Or is it totally weird to the question asked? Please do not down vote without any reasons. If there is one, please provide.
    – Arun
    Commented May 20, 2013 at 16:01

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