As much as you’d like to avoid or ignore them, bugs are a natural part of product development.
Even the most robust and mature software delivery process isn’t bug-free.
As counterintuitive as it might sound, the healthier your development process becomes, the more bugs you’ll deal with. It’s not that the number of bugs themselves increases, but you become more skilled in spotting them.
This can quickly become overwhelming.
That’s why it’s critical that product managers master proper bug management techniques to deal effectively with various bugs and production issues.
In this article, you will learn why bug management is important and techniques for minimizing their impact on your product.
Bug management is such a vital part of every product manager’s job because of:
Bugs are, in essence, items that occupy your product backlog. They require constant revision, attention, and prioritization.
If you allow your product backlog to become ridden with dozens of bugs, you and your team will have to spend a lot of energy to simply keep track of everything.
Ignoring bugs in the short-term leads to slower development in the long-term.
Working on bug-ridden features is harder and more problematic, both from a development perspective and a quality assurance perspective (the need to keep track of whether something is a new bug or a previously acknowledged one).
Bugs tend to impact the effectiveness of the product as a whole.
While a single UX bug probably won’t make a visible difference, ten of them can damage user experience and corresponding product metrics.
Over the last couple of years, I adopted a few techniques that have helped me tremendously when it comes to bug management. Some are common best-case practices, and some are approaches I developed on my own.
Their effectiveness and difficulty depend heavily on your context, so explore and choose from the following tactics:
Standardized bug templates are a must.
Although it might seem like common knowledge, it often slips out the window in early-stage products. The following usually occurs:
Avoid this mistake by embracing a templated approach early on. Here’s an example of such a template:
The goal of a template is for anyone to quickly understand and reproduce the bug without bothering the reporting person.
Let’s face it, most bugs won’t make it on the typical priority list.
That’s especially true if you deal with numerous stakeholders in bigger organizations.
What I like to do is to dedicate roughly 5-15 percent capacity each sprint for fixing bugs. I don’t count it in our velocity projections nor announce it publicly — that is, when presenting our plans, I don’t usually tell what bugs we plan to fix. Instead, I treat it as our internal affair.
It might not be the perfect transparency, but it doesn’t do much harm and makes my life easier since I don’t have to deal with pushy stakeholders complaining why we fix bugs rather than working on the next feature.
I choose my battles.
To decide whether we should dedicate closer to 5 percent or 15 percent of the capacity for various bug fixes, I often use the tech debt ratio.
The tech debt ratio is the ratio between our technical debt backlog and average velocity:
Tech debt ratio = technical debt / velocity
If we currently have 100 story points worth of technical debt in our backlog, and our current velocity is roughly 25 story points per sprint, then the tech debt ratio is 4. That means we’d need to dedicate approximately four full sprints to catch up on all known technical debt:
Tech debt ratio = 100 / 25 = 4
I usually agree with the team on what our tech debt ratio threshold should be, depending on:
If we agree that holding the ratio between 2 and 4 is optimal, then if it goes above the upper boundary, we dedicate more capacity during our sprints to catch up on the debt.
On the other hand, if it goes below the lower boundary, we allow ourselves to get more aggressive in feature focus and ignore smaller issues.
Individually discussing every new bug that appears is a time-consuming and wasteful activity.
Instead, approach triage issues with agreed criteria:
The most common approach is to assess the bug’s severity and how many users it impacts.
Bugs that severely impact many users should be fixed as soon as possible. Severe bugs that affect a few users or less severe bugs that impact everyone should be considered in upcoming sprints, while non-severe low-impact bugs might be put into the backlog and planned in the future.
I score bugs for severity and impact on a scale of 1-3, and then multiply those values. This gives each bug a score between 1 and 9.
We treat bugs that score 1 or 2 as low priority, bugs with a score of 3-6 as high priority, and we fix 9s as soon as possible.
The goal here isn’t to be scientific, but to quickly filter bugs so that we know where to focus our attention.
Regression tests are the best way to prevent unpleasantly surprised post-releases.
Regression testing involves testing older features and functionalities and sanity-checking if they still work. Sometimes implementing a change in one place might unexpectedly break a feature in a completely different place.
Ideally, you’d run a full regression with every release. But since regression testing is a time-consuming activity, it’s often unfeasible.
Here are some tactics to make regression tests more feasible:
Product bugs can quickly lead to various issues, such as:
To avoid these issues, product managers should embrace various bug management techniques.
These could include:
This is by no means a definitive list.
Depending on your product, context, and needs, you might need to embrace various approaches to deal with bugs. As always, choose whatever works for you and ignore the rest.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Learn more →
