tags:

views:

416

answers:

10

When planning and prioritizing what is to be included in a release, do you distinguish between bugs, feature enhancements and new features?

For example, do bugs always take priority - do you fix all known bugs before working on new features? Do you use a formal system for comparing the cost vs. value of each change in your backlog? And if so, do you compare bugs and features using the same formula? Is this different for commercial software vs. open source vs. in-house corporate software?

EDIT: Some great responses - thanks. While I had a preconceived opinion that you need to treat bugs, features, enhancements all the same, and simply select the work based on the cost/benfit of each, I think the reality is that this depends on your situation.

+2  A: 

I like to think that bug fixes should always come before enhancements and new features, in all cases. Even if the particular bug isn't bothering you too much as the developer, someone somewhere is having their day ruined when your little error pops up.

Fiarr
I disagree ... a bug that occurs once a day with a workaround of 30 seconds compared to an enhancement that will save 2 hours of work a week?
Martin
+2  A: 

We always look at the cost of fixing the bug versus the problems caused by it. Sometimes, it just isn't worth it to have every single bug properly triaged, root caused, then fixed.

Plenty of times a particular enhancement or new feature is being funded or at least strongly recommended to occur by a large/good customer, so that also affects matters.

Coxy
+12  A: 

This choice is called triage, a term from emergency departments in hospitals where they have to decide who gets treated (and sometimes, unfortunately, who lives and dies).

As with all business decisions, it's a cost/benefit problem. What is the benefit of fixing a bug or adding a feature? What will it cost (including the opportunity cost of not doing something else)?

Pick those that have the most benefit for least cost. What you're aiming for is the maximum bang-per-buck. Resources are limited, desires are not, the perennial problem of capitalism :-)

There's no point fixing a bug experienced by only one customer who's never going to throw more repeat business your way if it means a feature that will sell hundreds of copies is dropped in the meantime.

For what it's worth, our company has a database of requested changes where customers can basically vote for what they want to see in upcoming versions of our products. The actual creation of these requested changes in that database is limited to the sales force since we don't want all sorts of requests showing up without being evaluated and discussed at least a little bit with the customers.

In addition, we regularly approach our biggest customers (in terms of revenue generated) with the list to figure out what features should be added (they are free to suggest their own desires as well, which also get entered into the database - obviously voting power depends a bit on revenue).

This is quite separate from our bug system although quite often bugs are raised which are actually new feature requests, and they're shipped across to the new features database. It's possible that this may even happen for real bugs that are considered low-impact or have a suitable workarounds in place.

paxdiablo
I agree with everything you say ... except watch out for your last sentence. If that customer who you are not fixing the bug for starts to talk to people about you, you may start losing business.
Martin
That's a good point (and is part of the potential cost of not fixing a bug).
paxdiablo
I'll let the community pick the "selected answer".
Ed Schembor
+1  A: 

distinguish, yes.

bugs take priority, yes.

all critical / normal priority and above bugs first, yes.

yes, the 80/20 rule.

no, bugs and features have to be treated differently because they are weighted differently.

yes, all commercial, open-source, and in house applications have their own way to do things.

As an example, FogBugz uses Evidence Based Scheduling and is the only management/tracker that i know of that uses that formula.

Hope that helps!

Robert French
+3  A: 

We ask our users. We have a niche product, and a small user base.

Seriously, the users group are paying maintenance, or thinking about buying.

So we ask them what they would like.

They suggest fixes, ask for new features.

We tell them about the development roadmap: because we have things we want to do to the product , due to times changing, design ideas. Changes to regulations.

And if every customer says "we really need feature X" : then it'll come next.

If they say "you guys need to fix the bug where I click there an it doesn't do blah:" then that bug gets fixed.

Commercial software: with the customers voting for changes. Of course, we take their choices on advisement: the company have other things that are thinking about.

Tim Williscroft
+1  A: 

You have to look at it from the standpoint of what the bug is. A show-stopper bug is always number one priority. If people can't log in or critical data can't be entered or adjusted, etc. then that must take precedence over pretty much everything.

Bugs of lower significance can be worked in as need be. We may delay fixing a bug becasue we know we are working on that section for an enhancement next week. Then the bug fix will go with the enhancement. We may delay fixing a bug if it is minor and a planned enhancement will replace the code entirely shortly. A major enhancement might take precendence over fixing some typos on the interface. A client may tell us that this other project is more critical and to do it before fixing the bug (our software is highly customized by client). It all depends on the affect of the bug and existing plans and corporate politics once you are past the show stopper. A bug that is bothering a major client may take higher precedence even if it seems minor to the developer. If the CEO wants it fixed now, doesn't matter how unimportant it seems compared to the rest of the workload, it gets fixed now.

HLGEM
A: 

For bugs, it's pretty simple: If you're going to fix it, fix it before you write any more code. Why? The more code you add, the harder the existing bug will become to find.

If you're okay with the idea of the bug never being fixed, by all means triage it over and add features.

kyoryu
A: 

Bugs? We have no bugs. They're undocumented features.

For us the choice is always based on business decisions and as a developer I have no input beyond offering my opinion on what should be top priority. More often than not, features win over bugs because adding features "appears" to the business area like progress is being made and bugs that I could have fixed a year ago continue to exist because the business side only wants to see "progress". Triage is great if your allowed, but all too often in the corporate environment, it's about visible results, not functionality.

BBlake
A: 

One thing did not mention so far the severity of the bug. If the bug has high severity (like crash , can not pass duration test, and it surely depends on what kind of application you have) ,you should definitly fix it first before adding new feature.

pierr
+1  A: 

Point 5 of The Joel Test: 12 Steps to Better Code makes a compelling argument (in my opinion) that it's a good idea to fix bugs before writing new code.

Tom