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.
the agile admin 
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…
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.
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.
lol 🙂
So how does one improve processes if we cannot tell if something arose through development weakness or external expectation changes? If we know something is a bug then we can measure rates of bugs and identify causes or flaws in our processes, this is why we differentiate, they are not the same and we should not pretend it doesn’t matter.
From the article:
“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.”
From prior comment discussion:
“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.”
I don’t know that I have something separate to add to that in response.
The problem is that there are *three* categories of change: bugs (bad code); defects (code, wrong behavior); and enhancements (no code, desired behavior).
For the most part, everyone can agree when something just doesn’t work. That’s a bug.
And everyone can agree when a feature is simply absent. (You may not agree that the feature matters, but you can agree that it’s not there.) That’s an enhancement request.
Sometimes a feature doesn’t behave as a user expects. (You may not agree that the feature should behave in that way, but you can agree that it doesn’t do what that particular user expects.) If you agree that the designed behavior is not the desired behavior, that is a defect. If you disagree, it is an enhancement request.
You can process defects and enhancements the same way if you like, but giving them a different name does help with prioritization (*in general*: bugs > defects > enhancements). And, most importantly, your customer doesn’t question your commitment to quality or your intelligence because you aren’t asking them to call things that you agree are problems “enhancements.”
so who cares is what bucket of money pays for it. New work can be capitalized…production bugs cannot they go against a maintenance budget. So although the dev team doesn’t care…the project team should
And that’s a good point, managing your capital vs expense. But the question is – how much time should the DEV team waste their time not doing either features or bugs but instead arguing about it? At most some project person should dump it in a bucket given 5 seconds of thought and your org’s guidance. But even that is overkill, I’ve worked at very large places that just allocated dev time as “a quick analysis shows 80% capital and 20% expense so we’ll just use that as an overall allocation of the dev budget” and it was fine. You may be looking for unnecessary precision, and unnecessary precision takes time and effort that is waste.
You got a development team and a support team. They are funded differently. Also, development team can miss features if they know support team will “fix” the missing features as bugs. Missing features should be rerouted back to the development team so they do not take advantage of support team – financially. New features are funded while bug fixes are not.