Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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 May 19 '13 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 May 19 '13 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 May 19 '13 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 May 19 '13 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 May 20 '13 at 11:31
show 4 more comments

5 Answers

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.

share|improve this answer
    
+1 The Joel test came to mind as soon as I read the title! –  jkoreska May 20 '13 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 Feb 27 at 4:02
add comment

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.

share|improve this answer
    
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 ... –  Marjan Venema May 19 '13 at 18:08
add comment

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?

share|improve this answer
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 May 19 '13 at 20:34
add comment

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......

share|improve this answer
    
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 May 19 '13 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 May 21 '13 at 11:12
add comment

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 :)

share|improve this answer
    
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 May 20 '13 at 16:01
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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