Bug Fixes vs New Product Features: How to Prioritize

No developer joins the company to spend days on bug fixes.

People join teams to build innovative features, solve challenges, and have fun.

 

 

Let’s agree, there’s little fun in bugs. 

The question is, can we find a solid routine for balancing feature prioritization and fixes? 

This article will talk about why there’s no single strategy – and boil down all existing approaches to fundamental principles of product prioritization methods. 

 

Do All Products Need to Prioritize Bug Fixes?

Generally, yes.

If a team hopes to stick to the market, they need to remove errors all the time.

Ideally, your team should be able to do it before users send in a report or two.

So, not only each product needs bug fixing – it should also be a reactive one. 

 

Difference Between Reactive and Proactive Approaches to Bug Fixes

The reactive approach deals with mistakes that were identified by the software development company during its testing and analysis or by users.

It’s not like the team was deliberately looking for errors – they just happened to stumble upon them.

So, they find it, fix it, and move on to their tasks.

The proactive approach prefers the deliberate identification of issues.

If the team is able to quickly find errors in the product before issues casually reveal themselves, they can improve user experience and increase feature prioritization. 

Of course, a proactive approach isn’t perfect.

If the team doesn’t have a product prioritization framework, it might take a lot more time than a reactive one.

In case testers and developers don’t know where to look, they can spend days and even see errors where there aren’t ones. 

Here’s the kicker:

A lot of times IDEs and testing software show errors where there aren’t ones. It takes experience and confidence to identify these situations – and avoid the slippery slope of looking for a mistake where there’s none. 

However, if the team is determined enough and is ready to put in the hard work of figuring out the long-term system, they will be able to find mistakes proactively – and quickly.

But getting started with product prioritization methods, you have to address some challenges. 

 

Challenges of Setting Up a Bug Fixing System

Distributing time between bug-involved tasks and new development requires more than just adopting a couple of methods.

The team lead and members need to shift their understanding of a coding process, claim responsibility for their work, and find tasks that suit individual skill sets. 

 

Why Do Product Prioritization Methods Fail?

• Personality differences: not all people have the same level of attention to detail. For some developers, identifying a bug is an easy task. They don’t get lost in the codebase – in fact, some even like the process. Others will take twice the time and still perform a worse job. It’s not necessarily for the lack of trying – people just have different attention spans and attention to detail. 
• Skills: some developers are more skilled in conceptual work that involves making up new user flows and identifying opportunities. For others, such creative work is difficult – and they would instead do a step-by-step task. Finding ways for developers to apply their strong suits without offending anyone in the process is tough work. 
• Ambition: in an ideal team, all developers would be aware of their strong suits and ready to step in for team members. In reality, people might dislike specific tasks even if it suits their skills. Even if a developer is really good at spotting bugs, he/she still might ask – why me?
• Lack of understanding of the project. The lack of motivation often boils down to the belief that the bug is so unessential that users won’t notice it. ThisIn a proactive approach, this attitude is off the table in a proactive approach – since the team will always be dealing with small errors. In fact, the entire point is to prevent those from becoming a huge issue. 

Prioritizing bug fixing is not just a management problem, it’s a leadership issue.

Rather than worrying about establishing task boards and assigning deadlines, the project manager should focus on a long-term product prioritization framework.

All the members need to understand how they contribute to the project. 

Approaches to Leading the Bug Fixing Process

In a nutshell, there are two ways to organize the bug fixing process.

Some teams believe that each developer should be responsible for cleaning up their own code.

Others think that developers who are good at building not necessarily should be stalled by refactoring.

The job is left to other developers – whose skills are suited specifically to that. 

There’s also a third case. When a team works a lot with graphic designers, illustrators, artists (like in game development), their needs should also be considered.

While developers are busy with fixes, should an artist wait? How to prioritize features?

There are only two roads here.

Refactoring Own Code

Rewriting the code of other people is much harder, especially if it’s not properly documented.

Even large organizations often run their codebases on tribal knowledge – the specifics of the code are familiar solely to developers in actions. 

So, to avoid miscommunication, it’s faster to hold developers accountable for their own code quality. 

 

Disadvantages of the method

• Some developers might take a long time to fix code. In any team, there’s bound to be a member that just doesn’t do well with details (and incidentally, can be very valuable when writing new stuff). 
• Each developer has different quality standards. Some team members will hold their code to high standards, while others will ship what works. Establishing a common standard is important – but be aware that it’ll take some time, too.
• No peer check. As any creator, a developer tends to be biased about own code. When you are working on the feature for a while, you might miss out on some bugs or treat them as a naturally recurring part of the functionality. Setting up peer-to-peer review systems can be a solution for this issue. 

Dividing the Team’s Responsibilities by Skills

Not all developers are equally good at building and refactoring. Sometimes, you want a team member’s brainpower on a new feature, not necessarily clean up.

However, when developers are selectively involved in the production, their previously written code fragments are refactored by peers.

It’s not a given that they will like it. 

The main advantage of the method is that it allows capitalizing on the strong suits of your developers.

The production process never really stalls. You distribute tasks according to members’ proficiency – which, in an ideal scenario, is much better than an individual standardized system. 

 

Disadvantages of the method

• Miscommunication: project managers often fail to explain to developers the motivation behind rewriting someone else’s code. If this approach fails, it leads to conflicts among team members. 
• Incomprehensible code. Often, developers can’t read and understand well the code written by colleagues. However, it’s not a problem that you should regard lightly. If your developers struggle to read the code of others – you are in big trouble. If anything, this method helps to detect the issue, which is undoubtedly a good thing. 
• Putting off bug fixes. Bug prioritization is much easier when the entire team sets other tasks aside. However, if the team is only partially involved in refactoring, chances are, these members might get distracted with other work. 

The Ideal Scenario for Bug Fixes: Combining the Two Strategies

The final goal is to keep eliminating bugs without stopping production.

If the team only gets caught up in fixing errors, it will take months to start building new features.

When your product sales, the number of bugs increases a ton.

If stopping entire production is to become a habit, you might stall the progress for years. 

 

So, How to Prioritize Product Features?

So, production has to stay.

Which means you need to distribute tasks selectively anyway.

However, keeping personal accountability is still important for healthy communication. 

 

How to Prioritize Features: Product Managers’ Guide

Strong Onboarding

Every developer that joins the team should learn how to code according to your company’s standards.

Often, project managers are eager to maximize their resources.

Newcomers enter the codebase and start doing things their way.

In the long run, you’d be better off giving a new developer a month to adjust and re-learn coding standards – according to the way your team does things. 

 

Documentation Is the Priority for Bug Fixes

Even more so than bug fixing.

Ultimately, prioritizing bug removal allows you to deal with existing problems – but the focus on documentation helps you preventing documentation focuses, but issues.

Establishing and maintaining a strong knowledge base is a key to a proactive approach. 

 

Define Code Standards Based on Your Tech Stack

Using general criteria like “no more than 10 or 20 lines in a function” leads to confusion.

In some languages (like APL), 20 lines are definetely too much, while in Assembly, for instance, that would be too little. 

 

Custom Software Development Requires a Different Approach

A lot of information available on tech debt talks about refactoring left-over spaghetti code.

When you start from scratch, there’s even more pressure to come up with the right architecture and set up a solid foundation.

In this article, we give advice that’s applicable to both refactoring and custom product management.

 

Avoid Refactoring OCD

Developers always can create space for bugs.

It’s not a given that new code will be better than the old one.

Establish techniques that evaluate if code is bad enough to undergo refactoring. 

 

Get to the Bottom of the Problem of Bug Fixes

If you are dealing with hundreds of bugs in your backlog, the question is not how to get through them all.

The team should be asking why the system produces so many bugs in the first place.

Look for underlying architectural, functional, and business logic issues beneath the bug surface.

 

Always Strive for High Test Coverage

When you write tests for the codebase, make sure they cover 90% of the codebase. The more, the better. 

The guiding principle behind smart bug prioritization is this: fix the cause, and then fix the bug.

If you just fix the bug crossing the problem of the backlog, it will undoubtedly reappear.

Treating the symptoms without addressing the disease is not healthy for your system. 

Methods for Bug Control

Now, it’s time to talk about tools.

After we’ve got down the conceptual approach to bug management, you can get your hands on tangible instruments.

But before you go and implement those, make sure you’ve understood the principles first. 

Prioritization Matrix in Product Management and Bug Fixes

We already established that in product management, feature prioritization and bug fixing should be constant processes.

However, the time/effort allocation can be tricky – you need to calculate the benefits.

So, collect them all in the matrix. 

 

Questions to ask in prioritization matrix for product management

• How much does it cost?
• What matters most to the customers?
• What is the difficulty level (use story points for estimation)

 

 

 

Weight Scoring

Critical bugs are fixed immediately.

Any issue that falls out of this range can be evaluated separately.

This is where weight scoring comes in – a process of grading tasks from 1 to 5 by their priority (lowers, low, medium, high, highest).

You can do it with default Jira functionality. 

 

MoSCow Prioritization Method for Bug Fixes

MoSCoW feature prioritization matrix allows you to display the context behind your bug evaluation process.

Weight scoring is used for most tasks overall, but I find that the MoSCoW method works specifically for bugs. 

 

Bug categories: 

• Must have – critical issues that should be fixed immediately
• Should have – mildly critical issues that should be addressed right after the critical issues
• Could have – issues that can be solved after more pressing production issues are dealt with
• Won’t ever have – bugs that can be deleted and never resolved

Here we come to another interesting point.

It turns out, not all bugs should be fixed.

If you procrastinate on some small bugs for a while and don’t really plan on fixing them, delete them from the backlog.

Otherwise, they will pile up and take up your attention.

Deleting bugs is perfectly normal practice – issues accumulate all the time, and some might have little to no impact on the system.

MoSCoW rule in Agile is a good way of communicating this principle to your team.

 

Kano Product Management Method for Bug Fixes

Efficient software is not the one with the perfect code.

It’s a solution that brings business value.

Thus, what the development team is doing should be synchronized with the overall business pace.

According to the season, market trends, user feedback, sometimes production absolutely must be prioritized over bugs.

Or vice versa. 

 

Kano Method Measures Customer Satisfaction

This Agile prioritization matrix puts user needs as a core priority for making development decisions. There are three types of needs. 

• Basic: the core functionality of the product that deals with essential customer requests. If their features were to stop working, users will not be able to use the application. Any bugs concerning basic needs should be addressed right away.
• Performance: users notice these issues, but they don’t impact the core performance. However, if too many accumulate, users won’t be satisfied. You can postpone these bugs don’t strive to eliminate all performance bugs. The 80:20 ratio of fixed vs. unfixed is a realistic standard. 
• Attractive: innovative features that surprise users and help you stand out from the competition. Be sure to prioritize attractive features at least one sprint per quarter. This is how your product can stay relevant, attract attention, and scale. 

Opportunity Scoring

Ways in which developers perceive their product is often fundamentally different from what users want.

It’s useful to conduct feedback evaluations to make sure that your vision is aligned. 

In an opportunity scoring, you assign the priority score to your features according to user feedback. 

• What features are users most satisfied with?
• Which features drive the most complaints?
• What functionality is essential for sales and revenue generation?
• Whichchanges will impact the user experience the most positively?

A lot of teams are tempted to answer these questions on their own.

However, such opportunity scoring  is not objective.

Gather the focus group and ask these questions directly.

If possible, ask existing loyal customers. 

Summary

Teams often fall into a false dichotomy of “either development or bug prioritization”.

In reality, productive teams accomplish both.

To have time and resources to move in all directions, you need to prioritize a proactive approach over a reactive one.

Establish documentation, conduct thorough on-boarding, and pay attention to engineers’ skills. 

It’s tempting to let one matrix or management approach to governing your bug fixing process.

However, you need to adapt your practices to your tech stack, team skills, and user satisfaction.

So, we recommend using all the metrics to get a full view of the work scope.

But before that, understand and communicate the concept behind your approach. 

Focus on fixing the underlying causes, and only then remove bugs from the backlog.

If the reason isn’t at all serious, just delete the bug.

The bug is not an enemy – poor quality is.