Technical Backlog

Why would you need to handle them any differently?

The Product Owner doesn't "own" the Product Backlog. The Product Owner is accountable for certain things related to the Product Backlog, such as ordering the items within it and ensuring that the Product Backlog is "transparent, visible and understood" to the appropriate stakeholders. The Product Owner is also accountable for creating and communicating Product Backlog Items. However, the Product Owner can delegate to others. In some cases, such as for highly technical work, the Product Owner may delegate the creation of the Product Backlog Item to the Developers.

Anyone "wanting to change the Product Backlog can do so by trying to convince the Product Owner". If there is a question about what the work is or the value of doing it, the Product Owner (or, perhaps, the person who the accountability for ordering Product Backlog Items has been delegated) must be convinced. For highly technical work that supports the Developers, this often means that the Developers need to be able to express why doing the work will yield value for some stakeholders so the work can be ordered among all the other valuable work.

It sounds like this is technical work which should have been taken care of but wasn't (updates, migration). That's technical debt.

There is a basic three part strategy for dealing with technical debt:

1. Stop creating debt. Have a release quality Definition of Done that stipulates the technical standards necessary for work to be of suitable quality (e.g. endpoints, environments), and honor that standard.
2. Quantify the technical debt incurred so far on the Product Backlog. The Product Backlog should tell the truth at all times about how much work is currently believed to remain for a Product over its lifetime, including any technical debt.
3. Come up with a suitable policy for paying off a certain amount of technical debt every Sprint, allowing for any losses due to context/task switching.

Now, consider your situation. Is the Product Owner able to engage -- sensibly -- with the Developers about the prioritization of technical debt, and its timely remediation in upcoming Sprints?

@Thomas

I always thought the PO owns the product backlog (and by reading online, seems most people think this way) but you're 100% correct and I am glad you brought this as I found this good article

https://www.scrum.org/resources/blog/myth-product-backlog-maintained-ex…

@Ian

While I agree some work could be technical debt, not all technical work is necessarily technical debt if we assume the below definition: "implied cost of future reworking because a solution prioritizes expedience over long-term design"

For instance, you may have designed properly an app relying in an existing XYZ API that the IT department in the company decided to change 9 months later for wathever reason. Regardless if your implementation was done properly, you now need to update that. That's not technical debt but it is technical work that needs to be done.

And to answer your question: Yes.

For instance, you may have designed properly an app relying in an existing XYZ API that the IT department in the company decided to change 9 months later for wathever reason. Regardless if your implementation was done properly, you now need to update that.

Not all technical debt is incurred consciously. Some may be incurred unconsciously, due to dependencies on other departments for example. Some of the outstanding work may very well be unforeseen. It's entirely possible for Developers to be Done and still build up technical debt in the Product.

The Sprint Retrospective provides a formal opportunity every Sprint for the Scrum Team to try and identify such issues, to improve the Definition of Done, and to keep a lid on technical debt.

How do you handle 'technical backlog' items within the 'Product Backlog'?

I have come across the below scenarios when there was a technical backlog:

1. Some task needs to be done before starting the actual story prioritized by the PO. In such case create a task and link it to the story (assuming you use some tool like Jira)
2. Some task needs to be done by the team like upgrades, patch update etc.
3. Some ad hoc tasks like the database end of life example you mention
4. Technical debt

I don't think they need to be handled any differently. But at times the development team may have to convince the PO on why the item is important and urgent and should be included in the sprint (could be done as a part of backlog refinement).