Keeping agile with zero-bug/defect policy

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.

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.

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?

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:

It’s a genuine bug and should be fixed asap: put on top of the backlog
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.
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.

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

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 🙂

Filed under: softwareengineering - @ 07:56

Thẻ: agile, backlog, bug, scrum

Thiết kế website giá rẻ

Danh mục

Keeping agile with zero-bug/defect policy