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.
Table of contents
Why is bug management important?
Bug management is such a vital part of every product manager’s job because of:
Cognitive load
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.
Impact on velocity
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).
Learn more →Damage they cause
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.
Bug management techniques
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:
- Embrace proper bug templates
- Dedicate capacity for bug fixing each sprint
- Use the tech debt ratio
- Use triaging to prioritize quickly
- Conduct regular regression testing to avoid surprises
Embrace proper bug templates
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:
- A new product is built, so there are no proper processes yet
- Bugs are sporadic and are reported on an ad-hoc basis
- Over time, the product matures, and the number of bugs grows, but the processes don’t catch up, and people are still writing one-liner explanations of what the bug is
Avoid this mistake by embracing a templated approach early on. Here’s an example of such a template:
- Summary — One or two sentences describing the nature of the issue
- Environment — Where did the bug occur? What environment (staging, prod?) and device (Android versus iOS? Chrome versus Safari?)
- Steps to reproduce — What exact steps should one take to reproduce the issue on their own?
- Expected outcome — What’s the expected outcome of following the steps to reproduce?
- Actual outcome — What’s the actual outcome of following the steps to reproduce? What’s the difference?
- Attachments — Screenshots and videos always go a long way
The goal of a template is for anyone to quickly understand and reproduce the bug without bothering the reporting person.
Dedicate capacity for bug fixing each sprint
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.
More great articles from LogRocket:
- How to implement issue management to improve your product
- 8 ways to reduce cycle time and build a better product
- What is a PERT chart and how to make one
- Discover how to use behavioral analytics to create a great product experience
- Explore six tried and true product management frameworks you should know
- Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
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.
Use the tech debt ratio
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:
- Current priorities
- Stage of the product
- Stability vs speed needs
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.
Use triaging to prioritize quickly
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.
Conduct regular regression testing to avoid surprises
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:
- Automate your critical path — You should test the most important parts of the product (such as payments) with every new change, and test automation
- Have regular regression tests — If you release too often to undergo regression tests each time, aim to do them periodically. I’d encourage at least one full regression test per quarter as the bare minimum
- Engage the whole team — You don’t need a QA to perform regression tests. Instead of asking your QA to spend a whole week doing it all alone, ask them to organize a team-wide regression session that might take less than a day
Final thoughts
Product bugs can quickly lead to various issues, such as:
- Excessive cognitive load when managing a backlog and priorities
- Slowing down the team’s development speed
- Damage to product performance and user experience
To avoid these issues, product managers should embrace various bug management techniques.
These could include:
- Using bug management templates
- Dedicating capacity for bug-fixing each sprint
- Using the tech debt ratio to plan accordingly
- Having a streamlined triaging process for quicker assessments
- Conducting regular regression sessions to avoid surprises
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 generates product insights that lead to meaningful action
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.
