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 