It’s often difficult to know the perfect time to be prioritizing features and bugs of a project. And sometimes, it can be hard to really tell which is which. I’m going to explain the terminology and the thought patterns around these elements in software development, and share how we work them at Revelry.
As we work in sprints to deliver incremental bits of software, we prioritize work around product requirements. But, when we are faced with shifting urgencies, we need a protocol for prioritizing features and bugs, plus the work that surrounds them.
Glossary: Understanding the terminology and the thought patterns
What is a “feature”?
A feature is a requirement within a system. Features can include updates to existing requirements or completely new requirements. They don’t have to be visible. Sometimes they are purely data related, sometimes they are purely interface related; sometimes they are both.
What is a “bug”?
Bugs can be failures or crashes of the user-facing system. We also consider feature regressions to be bugs.
What is a “feature regression”?
A feature regression, also simply known as a regression, is a regression of a previously implemented feature. These can be caused when new work overwrites or interferes with existing features that we don’t want to change.
What is an “edge case”?
An edge case is a certain kind of use case for a feature. Essentially, it is a case within the bounds of a built feature that tests the feature’s limits. If this edge case causes a failure, then the feature needs more work. More often than not, an edge case is the root of under-developed feature work.
Mislabeling a feature as a bug
A common use case for mislabeling is a feature gap. Feature gaps are often mistaken for bugs. A feature gap does not cause a crash or return an error message to the user. But, a feature gap can cause an unfinished workflow to be incomplete. We see a feature gap as a blocker to the completion of the workflow, rather than a failure within the loop.
How do these terms play into prioritization?
Put simply, they don’t. It’s all the work, and we don’t automatically prioritize bugs over features.
We prioritize based on what is going to make the most impact on the business that the software is serving and the customers interacting with the product. Sometimes, features are more important to the end user than a fixed bug; sometimes, it’s the reverse.
Prioritizing Features and Bugs at Revelry: Examples
Example one: prioritize the feature
Let’s say you have a newly launched product that has a sign-in form. At the same time, your product has an administrative interface that allows you (and only you) to see who has signed in to your product. The sign-in form doesn’t yet have password recovery as a feature. Your administrative interface was built to see each user’s geolocation. These are two features: the latter has been implemented, and the former has not.
Your administrative interface functions well, but a recent change to the codebase removed the ability to see the geolocation. This is a bug. You can prioritize a bug fix or prioritize a feature. Since you’re not terribly concerned about seeing the user’s geolocation, but you are focused on retaining your user base, you would prioritize the feature before the bug.
Example two: prioritize the bug
You have a product that is scaling well and your engineers are working on improvements that will definitely take your business to the next level. The team is very excited about these enhancements.
Suddenly, 50% of your product’s users are seeing 404 errors on the pages that they normally use. This happened after a recent migration to the database, causing some of the references in your codebase to become stale. Operations have basically come to a standstill.
The prioritization in this case is easy: you would prioritize the bug. You must drop the feature work until your operations are back up.
What do both of those scenarios have in common?
We prioritize usage and value when assessing whether to work on a feature or a bug. These are the standards that make the biggest impact for software product delivery.
Aren’t bugs a bad thing? Shouldn’t we avoid them at all costs?
Bugs are notorious, but they are by no means taboo. Bugs are normal within our process and within the software development world in general (see “Software has bugs. This is Normal.” by Signal v. Noise).
For this reason, the work that we perform fixing bugs is visible and yes, billable, to our clients. We don’t hide our bug fixes in a back room like alcohol during the Prohibition.
I like to think of software development like cooking a great meal; a mess (le bugs) is made at the same time as the meal (le product).
But, we can certainly guard against bugs.
There are ways to clean as you cook, or to even prevent the mess to begin with. However, there is no secret technique that will guarantee you have zero bugs. If someone tells you this, run away! 🏃 👋
Guard against bugs with a solid shared knowledge of system requirements and expected functionality.
Software engineers, have you ever been on a project where no one really knew what was supposed to happen for a given feature? This will increase the likelihood for bugs times ten.
The engineers and stakeholders who are writing new features need to have a shared understanding of how the existing system is supposed to work, and how they want it to work after the feature is done. Here’s how to achieve this:
- Ensure that there is a frictionless way for stakeholders to communicate in a shared space.
- When an engineer has questions about how something should work, answers should be within their reach.
- When a product owner isn’t sure how something should work, and they need to collaborate with an engineer on developing a feature spec, there shouldn’t be 3 levels of abstraction just to talk to a technical person on the team.
- At Revelry, the way we use Slack provides us accessible, efficient communication. We let everyone talk to everyone, and ask that conversations are mostly kept in the open in order not to lose valuable contextual information in private messages.
- Maintain up-to-date, concise documentation of the system.
- Having a source of truth for how your system is supposed to function on a feature-by-feature and end-to-end basis will reduce the amount of noise around understanding things.
- As a test engineer, I document features in our codebase using Gherkin, and use these same feature files to drive our integration tests with.
Guard against bugs with testing.
Far and away the more tests you have, the more likely it is you will catch a bug before a user catches it. Automated unit and integration tests ensure that every time new code is added to your product’s codebase, you have a guard against regressions of the tested features.
Guard against bugs by implementing manual user testing.
Get people to use your system. Get really weird people who don’t know how to use the system to use your system. Let them be chaotic. We have a special group at Revelry that we let run loose on our systems; they are actually called the chaos team.
Simple, elegant product solutions
Keep solutions simple. The more complexities there are in the software you build, the more likelihood there is for bugs. This goes for the software, its integrations, the operating systems it runs on, the hardware it runs on, and more. Lets make the world a better place by prioritizing features and bugs a bit more often!
Keep it simple, and there’s less to worry about.
Find more of my writing here!
We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.