It happens. Once again. 2nd level support teams (outside of scrum/agile) raised new incident towards the scrum teams (3rd level support).
How to prioritize work between business requirements and non-business requirements where PO is focusing on business requirements primary?
Product Owner should not focus on business requirements only.
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.
Option 1: Buffer (15-20%) in your sprint
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 the team.
Option 2: Plan the sprint for 100%
We found it a better solution to plan the sprint for 100%. Once the support ticket arrives, the PO 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 SLA. Which, in most of the cases we observed, were not defined good 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…
Option 3: Firefighters
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 firefighter team as soon as possible by solving root causes (let the 2nd part of the teams to focus on this).
Option 4: Hold a line!
Let one team member holds 3rd level line to triage problems, sort them and advise PO to include them to the sprint. Rotate 3rd line support in the team. BTW, that helps build sustainability a lot.