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?
The basic defect management process
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:
- Finding bugs
- Documenting bugs
- Reproducing bugs
- Fixing bugs
That sounds simple, right?
One of the first questions is: OK, and where do I prioritize my bugs?
Bugs vs feature requests
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).
What’s the job-to-be-done?
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.
So, how do we prioritize bugs?
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:
- Does a bug affect one of the major flows in your product? (For example A user can’t create a new project in your project management software)
- What is the estimated number of users who will encounter this bug? How important are these users for you?
- How big will the effort to fix the bug be?
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:
- Importance (of a feature request or bug fix)
- Satisfaction (of the user with a feature request or bug fix)
- Opportunity (which is gained through the implementation of a feature request or bug fix)
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.
Wrapping it up.
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.
What is a bug report? Here’s our definition of a bug report.
This article is brought to you by Usersnap – a visual feedback & bug tracking tool, used by software companies like Facebook, Google, and Microsoft. If you’re new to bug tracking, issue management or web development in general, you might wonder what a bug report is. In this blog post, I try to answer this…
Bug Tracking explained in 7 funny GIFs
Every software has some bugs. We as developers have to deal with that fact. And no matter how hard we try, errors creep into projects. We talk a lot about the topic of bug tracking (also on this blog). But today, we’d like to bring some fun in here. So we collected some of the…
Don’t listen to your users. Let them show you.
Today I stumbled upon something quite shocking. I got hooked while re-reading a couple of our blog posts on the topic of customer support and how you should engage with your customers and users. In this blog post I’d like to show you what we got wrong and why you should not listen to your…
Launching bugtrackers.io – Here’s what we’ve learned.
Maybe you’ve heard the news. We at Usersnap launched a little side project, called bugtrackers.io. Displaying stories of digital crafters and showing real people behind pixels, bytes and bug reports. That’s the vision for bugtrackers.io. Starting with three interviews bugtrackers.io went live on April 16th. Following some great feedback on our social media channels as…
How to create an excellent web design for your blog
“It is not what you say that matters but the manner in which you say it.” This famous quote by William Carlos William is as relevant for blogging as it is for real life. Although whether the “what” is important or not (especially in educational blogs) is debatable, the “how” is definitely a factor you…
Inside Usersnap: Meet the all new Personal Lists
The last months were spent by the Usersnap team on building an all new Usersnap Dashboard with so-called Personal Lists which are announced today. We’re super proud what the whole team achieved and like to show you some insights on building it. The new Personal Lists will not only help you to be faster in…
Get experts insights & cutting edge ideas for digital product development.
We have asked six experts to bring you lessons learned about user testing and product development.