Is It a Bug Or A Feature? Who Cares?

Today I’ve been treated to the about 1000th hour of my life debating whether something someone wants is a “bug” or a “feature.”  This is especially aggravating because in most of these contexts where it’s being debated, there is no meaningful difference.

A feature, or bug, or, God forbid, an “enhancement” or other middle road option, is simply a difference between the product you have and the product you want. People try to declare something a “bug” because they think that should justify a faster fix, but it doesn’t and it shouldn’t. I’ve seen so many gyrations of trying to qualify something as a bug. Is it a bug because the implementation differs from the (likely quite limited and incomplete) spec or requirements presented?  Is it a bug because it doesn’t meet client expectation?

In a backlog, work items should be prioritized based on their value.  There’s bugs that are important to fix first and bugs it’s important to fix never.  There’s features it’s important to have soon and features it’s important to have never.  You need (and your product people) need to be able to reconcile the cost/benefit/risk/etc across any needed change and to single stack-rank prioritize them for work in that order regardless of the imputed “type” of work it is.  This is Lean/Agile 101.

Now, something being a bug is important from an internal point of view, because it exposes issues you may have with your problem definition, or coding, or QA processes. But from a “when do we fix it” point of view, it should have absolutely no relation. Fixing a bug first because it’s “wrong” is some kind of confused version of punishment theory. If you’re distinguishing between the two meaningfully in prioritization, it’s just a fancy way of saying you like to throw good money after bad without analysis.

So stop wasting your life arguing and philosophizing about whether something in your backlog is a bug or enhancement or feature.  It’s a meaningless distinction, what matters is the value that change will convey to your users and the effort it will take to perform it.

I’m not saying one shouldn’t fix bugs – no one likes a buggy product.  But you should always clearly align on doing the highest leverage work first, and if that’s a bug that’s great but if it’s not, that’s great too.  What label you hang on the work doesn’t alter the value of the work, and you should be able to evaluate value, or else what are you even doing?

We have a process for my product team – if you want something that’s going to take more than a week of engineer time, it needs justification and to be prioritized amongst all the other things the other stakeholders want.  Is it a feature?  A bug?  A week worth of manual labor shepherding some manual process? It doesn’t matter.  It’s all work consuming my high value engineers, and we should be doing the highest value work first.  It’s a simple principle, but one that people manage to obscure all too often.


Filed under General

5 responses to “Is It a Bug Or A Feature? Who Cares?

  1. tristanls

    So should these “things” in the backlog still be called “Bugs”? Perhaps a better term, informed by your actual description of the “thing”, would be “Rework”?

    • It’s fine to call them bugs, it just doesn’t mean anything from a prioritization point of view – it’s helpful to figure out why you have bugs escaping your dev/QA processes though. And, fixing bugs vs feature development has some capitalization ramifications I think. But changing the work from “Bugs” to “Rework” wouldn’t hurt, it might confuse some but also break some bad habits…

      • tristanls

        That makes me think of two lenses/filters for the backlog, the developer/technical lens containing features, bugs, chores, etc, and a stakeholder/priority lens containing work and rework.

        I’m thinking that the work and rework lens describes what’s important in the prioritization process, in other words, the things we want, and the things we didn’t get how we wanted them (highlighted in the post). The developer/tech lens still has the relevant info for the technical folks.

        Seems like there could be a mapping for a tool to offload the cognitive load of continuously remembering that “bugs” aren’t special for prioritization.

  2. Yeah we’ve been fretting over those two views – it comes up a lot (severity vs priority, bugs vs re/work)… What we’re doing now, since stakeholders only have the patience to think about the largest items anyway, is to expose just the epics to them. The linked tickets to the epic that appear in the proper backlog may be stories or bugs or requests or whatever. But they just see “list of epics.” The word bug not appearing anywhere doesn’t apparently prevent them from the “but it’s a bug!” syndrome, though, I’m finding.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.