Time management is key in most software development projects. Especially when a lot of bugs start to come in, features requests pop up and new feature releases are just around the corner, you might wonder how to manage the time of your developers most effectively.
And one of the first questions will be: How should I prioritize all these bug reports?
[otw_is sidebar=otw-sidebar-1]
I don’t want to get into too much detail here, but in order to answer the question on how to prioritize bugs, we need to understand the basic process of defect management.
The topic of bug tracking is – and should always be – a deeply integrated step inside the software development workflow.
On a basic level, the defect management process includes the following steps:
That sounds simple, right?
One of the first questions is: OK, and where do I prioritize my bugs?
[otw_is sidebar=otw-sidebar-2]
Looking at the question of how to prioritize bugs, we need to deal with the follow up question of how to prioritize bugs vs feature requests.
So, learning how to balance bugs is key here. And in order to balance bugs, we need to explain the concept of technical debt.
What is technical debt?
Basically, technical debt is a “concept in programming which reflects the extra development work that arises when code which is easy to implement in the short run is used instead of applying the best overall solution”.
Technical debt arises naturally over time. Bugs arise by taking shortcuts in software development. Instead of implementing the best solution during software development (which naturally takes a lot of time), we tend to take a shortcut (as it’s more time-effective in the short-run).
When dealing with the balancing act of bugs vs feature requests, we need to understand the overall business goals.
Understanding your business goals and how your goals as a developer are aligned to meet these business goals must be one of the first steps when it comes to prioritizing bugs and feature requests.
So, depending if your work success as a software developer is based on certain factors, bugs and feature request might be handled differently.
For example: If your work success is based on fixing any bug that arises, new feature requests will take longer to be developed. However, if your work success is based on developing new features for your product, bugs won’t be fixed as fast.
[otw_is sidebar=otw-sidebar-3]
So, how do we prioritize bugs? And how do we find a good balance for implementing new feature requests.
Here’s how we handle this topic at Usersnap.
Step 1: Collect information (bugs & feature requests)
We think that the more information we have, the less risky our decisions are.
So, while having limited development resources, we need to be information-driven when it comes to the decision of how important certain bugs and feature requests are.
Start collecting all your bugs and feature requests in one place. An issue management tool or a simple spreadsheet might be a great fit for that. Talk with customers, users, website visitors, your colleagues, and clients and ask them about their feelings when it comes to certain features or bugs.
Step 1 might sound like an easy one. However, it is the most time-consuming step in this process. You need to find answers to a whole bunch of questions. When collecting bugs you need to make sure to look at the following things:
Step 2: Assign values to each bug & feature request
One way to evaluate the importance of a bug fix or feature request is by looking at the value your implementation is causing. A bug causing a dead footer link might not be as valuable as a bug affecting the user’s payment.
Many teams already proceed with that step by asking “how important a bug fix or new features is”. Though I recommend going even further by making use of the framework of outcome driven innovation.
Step 3: Outcome driven innovation
We at Usersnap basically prioritize our feature requests and bug fixes by calculating the opportunity for each ticket. We use the opportunity algorithm developed by Anthony W. Ulwick.
This framework lets us focus on what’s really important.
An algorithm? Sounds complicated. Here’s the good news: It isn’t.
The algorithm includes the following three parameters:
By making use of this technique, you not only consider the importance of a bug fix, you also take other parameters (such as satisfaction and opportunity) into account as well.
Resources are a limited good (especially in small companies). Therefore, you need to make sure that resources aren’t wasted, but spent in the most efficient way possible.
The steps I’ve shown you won’t prevent you from working on the “wrong” bug fixes or feature requests. However, they will give you a clear outline of what’s really important and what’s not.
This article is brought to you by Usersnap, a visual bug tracking & feedback solution used by small to large teams.
[otw_is sidebar=otw-sidebar-4]
In today's market, product managers and CPOs can access a wide range of Enterprise Feedback…
In today's product management space, finding the right tools to navigate the complexities of the…
In the early days of personal computing, my generation used to spend a lot of…
For Product Managers and Developers, selecting the right, usability testing platform and tool isn't just…
Attention, Product Managers! Imagine a whole user journey where grasping your users' needs isn't a…
Why do the most successful product managers always seem to pay attention to the power…