Bugs, incidents, problems, and service requests in Agile

It happened once again. 2nd level support teams (outside of scrum/agile) raised new incidents towards the scrum teams (3rd level support).

How to prioritize work between business requirements and non-business requirements where the Product Owner is focused primarily on business requirements?

Product Owners should not focus on business requirements only. The Product Owner is responsible for the product that stands on multiple legs. Business, technology, support, bugs, research, etc. All of them.

That’s the reason for the word PRODUCT in the title. Change that.

It is only the Product Owner who set an order of requirements and therefore Product Owner needs to know about all backlog items regardless the backlog item type.

As a Product Owner, I need to understand support tickets deeper. I do not want to solve just the ticket. I try to understand the root cause of the ticket to remove the root cause and do not have another support ticket coming to my backlog.

Don’t solve symptoms, fix root causes.

To deal with tickets, there are multiple options.

Assign less to the sprint in the planning. That buffer might be of different sizes in different sprints based on the need of the business, product, or team.

The better solution is to plan the sprint for 100% of capacity.  Once the support ticket arrives, the Product Owner must decide if it should be included in the sprint (therefore breaking the commitment). I try to not break the commitment as much as possible. Therefore I want to find the root causes more thoroughly.

Urgent doesn’t mean it is also important.

A lot of tickets can wait. It is easy just to speak to the ticket reporter first and you will find that it is not so urgent. This means you can plan the fix of such a ticket in the later sprint. Of course, such a decision might be impacted by your Service Layer Agreemen. Which, in most of the cases we observed, were not defined well enough, or too wide. They included only response time without a proper process of investigation and triage.

Don’t forget to evaluate how many support tickets were planned, fixed in the sprint. Which of them arrived after the sprint has been started? Ask the team why they happen, how can we overcome such tickets in the future. What needs to be planned to fix their root cause. Can be the solution described in your FAQ? Maybe that is enough…

if you are fighting with tickets, establish separate firefighters group which will deal just with tickets. Let the rest of the team focus on new functionalities. Don’t forget to rotate people in the firefighter’s team to overcome ‘extinction’. Try to dismiss the firefighter team as soon as possible by solving root causes (let the 2nd part of the team focus on this).

Let one team member holds a 3rd level line to triage problems, sort them, and advise the Product Owner to include them in the sprint. Rotate 3rd line support in the team. That also helps build sustainability a lot.