Many software teams struggle with knowing how and when to handle those inevitable bugs. Whilst your company might have different terms including bugs, defects, incidents, issues, errors, faults etc., they all come down to something that is preventing the user from carrying out what they want to do.

So rather than differentiate between these terms, this post aims to help you tackle these issues and keep your customers and users happy.

Steps to tracking and tackling bugs

Let’s imagine you’re in the middle of a sprint where the sprint goal is to create a refer-a-friend feature for a home decor company. You’re busy pair-programming with your colleague to generate the unique referral links for users, when the Product Owner (PO) comes running over, arms waving in the air, and tells the team that one of your users is angry because they’re unable to change their delivery date for an order placed via the website. In an ideal world, this wouldn’t happen, and instead the following steps would have taken place:

Step one

The very first step when a bug comes in is to log the bug in your tracking software or on your physical board. The bug should contain the following information:

• Date and time user reported bug
• Error code and message (it’s a good idea to also ask the user for a screenshot of the error)
• Information on what the user was trying to do
• Device information - did the user experience the bug on a mobile device or on their desktop computer? What operating system and browser were they using?

Hopefully you already have a workflow in place for dealing with bugs, such as a customer support team or service desk who do the initial debugging, checking all the information has been included in the bug report, and identifying whether there are any other major issues that could be affecting the user at the moment. These initial first-line support teams should have some guidelines - ideally aligned to the company’s goals - so they can quickly identify whether or not an issue is critical.

So, if they only receive a call from one user who is complaining that they’re unable to change their delivery date, it shouldn’t mean that the Development Team drops everything to fix this (unless of course, this is your top customer and losing them would be detrimental to the business). On the other hand, if several different users have reported the same bug within a short period of time, that indicates that it probably is a bug that needs addressing quickly. The risk of customer impact becomes higher when you have more users complaining about the same issue, and as this can cause the company to lose money (e.g. many customers cancelling orders in a short timeframe), the bug should be given a higher priority.

Step two

After the first-level support team has given the bug an initial priority, it should be sent over to the Product Team. Let’s say the priority has been set to low by the customer support team: in this case the business probably isn’t losing much money and the sprint can continue as normal. The Product Team is responsible for making sure the right Product Owner is assigned to that bug to do further investigation. Much like Product Backlog Items or User Stories, the non-critical bugs can be prioritised alongside feature work. Whilst the priority provided by the support team is a good starting point, it’s not fool-proof.

The PO should also perform their own investigation to check the priority is correct. For example, they should try to identify how many customers are affected, as not all users will submit a bug report. Maybe you’re tracking change delivery date events in an analytics tool - a great start would be to analyse this data. If the issue appears to be affecting many users, even if there is only one bug report from one user, the business is likely be losing money and the bug should be given a higher priority.

Every bug should be evaluated to decide whether or not it’s worth solving. You can do this using your company’s goals (e.g. to increase repeat purchases by 12% in the next quarter); keeping top customers happy; or using the Pareto Principle. You will always have a backlog of bugs, but not all of them are worth spending the time and effort on. If you’re the sentimental type, you can always keep an archive of bugs that you won’t work on, so you can search for these later on - but don’t allow these to clutter up your Backlog (the inevitable so many bugs, so little time approach).

Step three

Once the bug has been prioritised alongside feature work, it can be brought to the relevant Sprint Planning session, or for those of you using Kanban, your weekly Replenishment Meeting. During this meeting, a quick decision can be made as to how to approach the bug - if it’s important enough the entire team may ‘swarm’ on the bug until it is fixed, or maybe one developer will agree to spend a maximum of 1 hour investigating the bug to identify what needs to be done to fix it. The outcome of that investigation should be an idea and estimate for how long the bug will take to be resolved.

Takeaways

If you’re a Product Owner, before hitting panic mode the next time you receive a bug report, take a moment to breathe. Rational thinking is required at this time. Yes, you may have just come off a phone call with a very irate customer - but what does the data show you? Is it just that one customer that appears to be affected or is it affecting many customers and in turn causing the business to lose money and damage their reputation? There’s no need to disrupt the entire Development Team and sprint for one user, so first check the data before deciding on the next steps. Of course, if the issue really is business critical, it’s a good idea to have the team investigate the issue for 30mins to 1 hour, and if it looks like it’ll be difficult to solve, consider cancelling the sprint and having the team ‘swarm’ on the issue. You can always begin the next sprint earlier than you had planned.

If you’re a member of the Development Team, learn how to say “no” and push back - not just on bugs, but also on features. After all, the Product Owner is a team member too, and they should respect your technical expertise and decision making. One of the fundamental principles in Agile is to have self-organising, motivated teams. That means you should have be empowered to make decisions, and that includes saying “no” to your Product Owner and stakeholders. If a bug report comes in and your Product Owner interrupts the team but your gut is telling you it’s not a critical issue, look at the data - are you seeing a large amount of application errors that are related to changing the delivery date? Are you able to track the events that are fired when a user tries to change their delivery date? Use data to your advantage - be proactive, submit the evidence and show the PO your findings. The majority of decisions in business should be driven by data, so if you really are self-organising and empowered to make technical decisions, your PO and the wider organisation should appreciate your ability to push back on unnecessary work.