Bug vs Feature: An Argument for the Pedantic

There is no technical difference between white and brown eggs, just as there is no significant difference between a bug and a feature. Still, like a brown egg, the term bug manages to leave a bad taste in the mouth.

Feature vs. Bug

Let’s first find decent and relevant definitions to compare these two terms.

In Essential Scrum, Kenneth Rubin succinctly defines a feature as:

“A slice of business functionality that is meaningful to a customer or user.”

Bug is a term that can have different meanings to different folks. For instance, some don’t differentiate between a bug and a defect. For this article, let’s stick with Ilan Goldstein’s definition of bug from Scrum Shortcuts Without Cutting Corners:

“A bug is a bug only if it is identified after a user story has been completed and accepted by the product owner.”

How Bugs and Features are Alike

Missing Functionality

Ernest Mueller points out that both bugs feature requests are simply differences between the product you have and the product you want.

In the case of a bug, a change made it through our SDLC (software development lifecycle), and users only discovered the undesirable behavior in production.

In the case of a feature, we’ve identified new functionality not currently present in the software that would provide customer value once implemented.

In both cases, to get from where we are now to where we want to be, we’ll need the development team to make a change.

Customer Value

Whether the change is a bug or a feature, it should provide customer value once implemented. The first principle of the Agile Manifesto states:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

If planned changes provide no customer value, why are we making them? Although this sounds like an obvious statement, valueless changes get prioritized by well-meaning individuals more often than we’d like to think.

Recently an engineer on my team logged a bug when they noticed some unpopulated tables. It was a pretty straightforward find as the same tables existed in the source and destination databases, and an automated process populated all tables except two. Hence, the tables not being updated must be an unexpected behavior missed in QA.

Since the issue was a bug, the Product Owner prioritized it, assuming it negatively affected production. Before backlog refinement, I asked the Product Owner to be prepared to speed to the business value of the change. During their research, the Product Owner discovered that no existing reporting used those tables. If the data didn’t serve some downstream purpose, why bother populating them?

Just because we discover a bug doesn’t necessarily mean it has value for our customers.

Once, while purchasing a home, we hired an inspector to inspect the property so we’d be aware of potential issues. One of the items on the report called out that the kitchen counters were not properly bolted down to the cabinetry. This construction flaw might have been a concern to a family with small children or someone living in an area prone to earthquakes, but it wasn’t that big of a deal for us. In our advancing adult stage, we tend not to crawl on the cabinetry.

Regardless of the issue type, any work the team performs should provide value to the customer.

How Bugs and Features Differ

Level of Uncertainty

Bugs almost always come with an extra serving of uncertainty. Feature requests typically focus on adding something new, but bugs fall into the realm of tweaking something already existing.

My husband and I watch a lot of house-flipping shows. To be more precise, he soothes me by snuggling up to me while I watch them.

Whenever someone takes a sledgehammer to a wall, my anxiety rises in anticipation that they’ll discover it’s a load-bearing wall. If I’ve learned anything from watching one-thousand hours of televised house remodeling, it’s that moving walls is risky.

These same principles apply to fixing bugs. Software developers will need to dig into existing code and figure out how to move the wall, and if it’s a load-bearing wall, they’ll have to find a way to work around that limitation.

A bug, by its very nature, indicates that the software is behaving unexpectedly. No one sets out with the intention of writing a bug. If you feel like your development team generates bugs on purpose, it might be beneficial for you to review the Scrum value of respect. Not knowing the root cause of the undesirable behavior adds extra complexity to implementing a fix. The team will almost always need to perform research before developing a resolution.

The extra uncertainty and research that goes along with resolving a bug is one way in which bugs differ from feature requests.

Opportunity for Process Improvement

Ernest Mueller pointed out another extra consideration for a bug: it exposes issues you may have in your process.

Remember, we defined a bug as something discovered after the user story has been completed and accepted by the Product Owner. So, if the application isn’t functioning as we intended, what is lacking about our processes that didn’t catch this flaw before it made it to production?

Were we missing acceptance criteria? Did something slip through our QA process? Was the customer unclear about what they needed? Should our coding standards be improved?

Great teams will determine what caused the bug and what process change will prevent additional future bugs. This extra step should occur with each Product Backlog Item of this type.

Making purposeful changes to our processes to prevent bugs contributes to continuous improvement that ensures technical excellence. This extra overhead doesn’t apply when building features.

Details Captured

Teams typically gravitate toward the user story format to capture feature quests. It’s best practice to have a template that documents the who, the what, and the why. There are variations on the user story template, but those are outside the scope of this article.

For bugs, this familiar format might not make much sense, and it’s harder to shove the request into that structure in a valuable way. Also, user story templates likely lack crucial information for fixing the bug.

Ilan Goldstein reiteration this sentiment in Scrum Shortcuts without Cutting Corners:

“Ensure that you set a consistent format that is as workable as possible for these technical types of stories. This same advice applies to capturing bugs in the product backlog. Although it is possible to document bugs utilizing the user story format, again, I find that taking this approach can become a bit contrived and confusing (like knocking a square peg into a round hole).”

The two most important elements to capture for a bug that aren’t typically relevant to a feature are the steps required to reproduce the bug and the actual vs. expected results. This information is crucial for the research phase to determine the cause and determine a fix. These elements don’t make sense for a feature.

Bug vs. Feature: The Great Debate

It’s a common joke in the software industry to say, “it’s not a bug, it’s a feature,” in situations where there is obviously a problem, but a clever person believes they can present it as a benefit.

This phrase gained popularity partly because traditional leadership styles force developers to defend their code. When something is called a bug, it implies that someone somewhere did something wrong. Some cultures track bugs as a quality metric, promising negative consequences for the developer that “wrote” the bug.

Some teams go as far as having a working agreement characterizing the definition of a bug. We cannot call the change a bug unless it meets a list of criteria.

Generally, these behaviors should be treated as a red flag, indicating an unhealthy culture. Are we beating co-workers up over mistakes? Are we focused on illogical metrics? Are we destroying psychological safety?

In the majority of cases, the reason the stakeholder or Product Owner might try to make the case to call something a bug is because they’re trying to get the change implemented more quickly, but should the type of Product Backlog Item (feature vs. bug) drive prioritization? Let’s tackle that topic next.

Prioritization Implications

Back to my home inspection story from before, in every home purchase, our realtor has pointed out that the inspection report is not a checklist of things the seller is required to fix. I suspect most home buyers feel the seller is obligated to repair all those items just because the inspector presents them in a list. This is not how a home purchase works, though. The buyer and seller must negotiate and agree on what items the seller will fix or compensate the buyers for. The seller is within their rights to choose to make no repairs or allowances and sells the home as is. The contract will typically expire if the buyer and seller cannot reach an agreement. My point is all of the items on the inspection report are negotiable. Negotiable also happens to be one of the qualities captured in the INVEST acronym that serves as a mnemonic for helping us remember how to write good user stories.

The Scrum Guide tells us:

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

The Product Owner accomplishes this by keeping the Product Backlog Items ordered and ensuring that the Product Backlog is visible and understood.

Imagine I went into your backlog right now and just removed whatever field your team uses to differentiate between features and bugs. If all Product Backlog Items looked the same, could you still rank the list in a way that ensures the highest customer value is at the top?

If your answer is yes, what value does it provide to differentiate between a bug and a feature?

If your answer is no, then why are your Product Backlog Items not written so that the value of all items is visible and understood? Would you attempt to argue that all bugs, regardless of their details, will always provide more value than a feature? I hope not.

Doctors would tell us that eating correctly and exercising regularly are prerequisites to remaining healthy. Between these two types of activities which one provides the most value? Given the following backlog, what would you prioritize first?

• Running 1 mile

• Eating more vegetables

• Eating fewer Carbs

• Doing ten sit-ups

• Limiting portion sizes

• Implementing weight training

The truth is, it depends. I wouldn’t say all the diet-related changes are the priority, nor would I say that all the exercise-related activities are the priority. It may be less important for someone with bad knees to take up running, and someone already following a Keto diet may not need to eat fewer carbs. Categorizing these tasks as either exercise-related or diet-related doesn’t do anything to help prioritize them. The same is valid for ranking your Product Backlog Items as bugs or features.

Again, I want to highlight a quote from Ernest Mueller:

“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.”

To maintain a healthy backlog, you need a way to rank PBIs based on the value the customer will realize upon implementation.

Zero Bug Fallacy

The Man vs. Bee saga is based on one man’s obsession to kill a single bee and how that resulted in the ruination of multiple lives.

Some teams’ dedication to immediately squashing all bugs is misplaced.

In Agile Estimating and Planning, Cohn states:

“An agile team has the goal of fixing all bugs in the iteration in which they are discovered.”

I think some teams take this sentiment too far and twist it to mean that all bugs must always be prioritized and fixed first over anything else. This fanatical approach essentially boils down to the difference between bug vs. defect. Anomalies are cheaper to resolve the sooner they are discovered. Cohn himself goes on to state:

“A defect found later (or not fixed during the iteration in which it was discovered) is treated the same way as a user story. Fixing the defect will need to be prioritized into a subsequent iteration in the same way that any other user story would be. Outside an iteration, the whole idea of a defect starts to go away. Fixing a bug and adding a feature become two ways of describing the same thing.”

In the same book, he also recommends that we should split time between feature development bug fixes:

“The product owner selects how much of an iteration should be directed toward bug fixing rather than new feature development. The product owner and team then collaboratively select which bugs fit within that amount of time.”

Avoid making your primary objective that or resolving all bugs. Instead, keep your primary focus on delivering customer value.

Works Consulted

• Is It a Bug Or A Feature? Who Cares?
• Essential Scrum: A Practical Guide to the Most Popular Agile Process
• Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools & Tips
• Agile Estimating and Planning

TLDR

There is no technical difference between a brown egg and a white egg. One typically comes from a brown chicken and the other from a white chicken, but an egg is an egg.

There is no meaningful difference between a feature and a bug, at least not in terms of prioritization. A previous change may have introduced one, whereas the other is a new idea, but a PBI is a PBI.