Deciding between adding new features and fixing known bugs in the software is almost never an easy thing. Especially with limited resources. In this article, we’re looking at how to prioritize your development work so it benefits both your business and your customers.

The Ongoing Software Release Cycle

Semantic versioning (SemVer) is one of the most popular methods for software versioning. It uses three numbers – separated by points – representing Major.Minor.Patch versions. In most cases, the meaning of each is as follows:

• Major – When this changes it means new features and/or functionality changes have been introduced with a significant risk to the user – usually incompatibility with older versions, hardware, operating systems, APIs, or other software.
• Minor – The introduction of non-breaking changes: features, functions, and bug fixes.
• Patch – Non-breaking changes in the form of bug fixes only, which could include stability and security improvements, but only if they too are non-breaking or backward-compatible.

GitHub co-founder, Tom Preston-Werner, compiled the SemVer specification found at semver.org. This resource sets out the rules for Semantic Versioning, but only in terms of assigning and incrementing version numbers. There are no rules stipulating how many minor and patch releases you can introduce under each major version of your software or app.

The benefit of this is that you remain in control of whether your next release is going to add or improve on a feature, or just fix a few problems you or your users have picked up. The drawback is that unless you have a strategy in place that helps you prioritize issues and features, you risk two things. 

You’ll either put too much effort into adding new features while neglecting a growing list of bugs and issues or try to eliminate every single bug before you even start working on new features. 

And both will ultimately see you alienating some of your users.

How do You Find Balance?

Frankly, there’s no perfect solution that’ll help you make the call on whether to prioritize fixing a bug or adding a new feature in the next release of your software. What your software does, who your customers are, and whether you’re following a Waterfall, Agile, Scrum, Kanban, or even RUP project management style are all relevant aspects to consider. 

And if you have a product roadmap, you’ll also refer to it for guidance on which features you should be working on first, and when to add them.

Writing about product prioritization techniques, Daniel Zacarias notes that:

The need to prioritize comes from a very simple fact: we just don’t have enough resources to work on everything we can come up with.

Of course, in the context of the piece he’s referring to new products or new features, but the statement can also apply to fixing bugs in software: no organization has the resources to focus only on eliminating bugs before working on new features. 

But prioritizing new features over bugfixes is also not sustainable. The goal of any work you do in your app or software should be to add value by making your product more useful to your customers. While we don’t doubt that all the features you have in mind would be useful to your customers, your software is less valuable to them if the performance degrades with each new release, and every new feature results in an older feature no longer working. 

And you never, ever fix any of this.

This is why you should be constantly working on both features and known bugs. And the only thing you should prioritize is which features to work on first, and which bugs are the most urgent to eliminate. 

Starting work on a new feature is always more appealing than slogging through existing code and looking for a way to make it work. The solution to this can be avoiding having the same people working on both features and bugs, to prevent the biggest share of attention going to feature development. 

Responding to a question on Quora in 2016, Sherif Mansour, product manager at Atlassian, shared the solution used at Atlassian:

Have a permanent bug fix team that is sized as a ratio in relation to your feature team(s). (…) Crucially, the people working on the bug fix team are rotated with every release, re-joining the feature team(s), and being replaced by the same number of people from the feature team.

Assigning Priority to Bugs and Features

Acknowledging that you should be working on bugs and features more or less simultaneously, and all the time, is one thing. But deciding in which order you tackle new features and bugs is another. 

Looking to your product roadmap or the techniques promoted by the project management style you follow will only help you in terms of the features. Typically, the decision to develop them involves calculating their ROI potential. Which, when you think of the importance of bringing value to our customers and to the company, is always a good idea.

But ROI can’t be used when prioritizing which bugs to fix first. The simplest approach is to rate each bug in terms of urgency and importance. You can do this by answering questions like:

• Does the bug affect primary or secondary functions?
• Is there a workaround, and if not, how critical is it to fix the bug?
• How many customers are affected by the bug and how will they respond if you don’t fix it?
• How long would affected customers be willing to wait for a fix?

Any issues that are deemed both important and urgent should be top priority, followed by important but not urgent, and then urgent but not important. 

You can work on any bugs that are neither urgent nor important whenever you have time. Or when – being ignored for too long – they lead to urgent and/or important bugs in future releases.

But always consider bugs and features in relation to your customers. This is critical for us at Handsontable. Each release – whether major, minor, or patch – will always deliver what matters most to the customers. 

Pay attention to the features that they’re requesting, and the bugs or issues that they’re complaining about most. At the same time, promote transparency. Let your customers see:

• what bugs have been reported, 
• what features have been requested, 
• which of these are being prioritized. 

We use Github for both issues and feature requests, while Atlassian uses one of their own products for keeping their users informed of feature requests and for bug tracking.

As we worked on the new architectural solution that would become the biggest change introduced with Handsontable 8, this approach helped us to identify more than 150 issues and bugs that we could resolve. The result was a release that improved performance and stability.

When in Doubt, Look to Your Customers

Having said all that, the above is probably the best conclusion to this post. And the best rule of thumb to follow is the never-ending bug vs. feature balancing act.  

Always go for what brings the most value to your customers within the expected timeframe (and what’s feasible, of course.) And plan ahead to anticipate the things that don’t seem important today, but may quickly become urgent in the future. If it’s something that answers a real market need, the ROI will follow.

What are your ways to prioritize new features and bug fixes? We’d love to read about your experiences in the comments.