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).

The Product Backlog is an emergent, ordered list of what is needed to improve the product.

What is needed to improve the product can come in lots of different forms, including technical work. Note that the Scrum Guide is very generic in using the term "Product Backlog items" as there is no one way or one type of work. Items, stories, features, tasks, tech debt, bugs, sticky notes, cocktail napkins are all potential forms of Product Backlog Items.

A Product Owner ought to be concerned with all aspects of their product and what is needed to improve the product. If an API endpoint is changing (could be outside of the Scrum Team's control), not spending time updating the product could result in the product not working any more. Seems important. 

Thomas provides some good advice about communicating, negotiating with the Product Owner. Think about how you can articulate the value and impact of this work and what might happen if you do it or if you don't do it. 

Practice has shown that one backlog ends up as a cluttered mess of items that are non-manageable after a month or two. Hence a need for several work-logs divided into particular categories - marketing, technical, maintenance, so on. Of course, it's subjective, if one work log works for you then well, whatever that works, works, right?

Enter the technical item into the backlog like any other item.

While the Product Owner is accountable for the Product Backlog and has the final say in the ordering of items, Product Backlog refinement is a collaborative effort involving the whole Scrum Team. As the Scrum Guide states, "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner." Conversations and collaboration between the Product Owner and developers regarding technical backlog items (or any PBI's for that matter) are completely appropriate and encouraged. The developers can share their insights, and together with the Product Owner, they can determine the best course of action for prioritization. Only the Product Owner has the final say on the order and priority.

Practice has shown that one backlog ends up as a cluttered mess of items that are non-manageable after a month or two.

@Maciej, that is not always the case.  Yes, I have encountered this issue but it is not the norm in my experience.  This occurs when no one takes the time to maintain and manage the backlog.  Part of that maintenance is deciding when something will never be done and dealing with the Product Backlog Item accordingly.  I have been involved with this activity on more than one occasion as all 3 roles described in the Scrum Guide.  

Hence a need for several work-logs divided into particular categories - marketing, technical, maintenance, so on.

Also tried this but it became even more difficult to maintain and we ended up with several work-logs that were a clutter mess of items that were non-manageable.  

The best option from my experience is to have a single body of work that identifies all of the work necessary for the product's success and life.  It has to be constantly reviewed, ordered, refined, and used. Those are activities that requires all members of the Scrum Team to participate or the efforts will be fruitless.  And you have to be realistic about the decisions. Asking "this has been in the Product Backlog now for 3 months. Do we really think it is needed and if so, why have we not discussed it?" is one of my favorite tactics. 

To tie this back to the original post...

The Product Owner is the one accountable for the contents of the Product Backlog.  But anyone on the Scrum Team can contribute to the items there.  In the case of technical items, those are more likely to come from the Developers and they need to make sure that the Product Owner understands the needs so that the items can be ordered appropriately.  Everyone that has responded previously have done excellent jobs of explaining the reasons.

I’ve seen teams try to run a separate 'Technical Backlog' before, and it almost always leads to a 'black hole' where tech debt goes to die because the stakeholders can't see it. Keeping everything in one Product Backlog - even the boring technical stuff - makes sure the PO actually sees the trade-offs between new features and system stability. Transparency is key!

The Scrum Guide is right about one backlog and one owner. The PO owns the backlog, but they do not magically understand infrastructure risk or technical decay. That is where the team steps in.

When we had items like API upgrades or database migrations, we framed them in terms of impact:

• What happens if we do nothing
• What is the operational or financial risk
• What user capability is blocked
• What future features become slower or more expensive

Instead of “migrate database because it is old,” it becomes “risk of outage increases, hosting costs rise 20 percent, and new scaling feature cannot ship.” Now it is a product conversation.

During refinement, the team explains the risk and cost of delay. The PO still prioritizes, but with better information. In healthy teams, technical sustainability is treated as part of product value, not separate from it.

What usually breaks this is when technical work is hidden as a side backlog or treated as “engineering stuff.” That creates tension later when production incidents start stealing sprint capacity anyway.

I agree with Julio, and I always said that we do a disservice to engineers and their leaders by not teaching them business language.   His questions are spot on, and it is a way to map your work to $ or value. 

Your tech-lead/architect mission is to give the PO a way to compare apples to apples, or at least keep it in the fruit family.

A provocative thesis:

There should be no purely technical tickets. 
Every ticket should either add value to the product or safeguard its value.

Examples of how technical tickets can add value include increased security, faster development speeds, and greater product stability. In extreme cases, the survival of the product depends on this. For instance, if an API that we use is withdrawn from the market, we must switch to its successor.
These tickets usually originate from the developers. They must convince the product owner that the ticket is valuable.
The PO must decide (or at least be accountable for the decision) whether, for example, the lowered risk is more valuable than a new feature.
A good developer can present the value in such a way that the comparison is as easy as possible.

If a purely technical task does not add value to the product, it should not be carried out. In Germany, we have an idiom for this: 'In Schönheit sterben' ('dying in beauty'), which describes things that are formally perfect but ultimately fail because they do not add much value.
It is, for example, pointless to solve technical debt in a component whose lifecycle is coming to an end or that is rarely used and almost never modified.
 

hmmm, I know what you are saying Benedikt and fully agree with it, but in this case the product owner is absent (he will be back when he figures things out), shouldn't the technical tickets just be in the language of the prioritizer?  

"shouldn't the technical tickets just be in the language of the prioritizer?  "

Yes, that's what I meant. 
The product owner should at least be responsible for prioritisation. The role of a prioritiser is then that of an delegate or representative of the product owner.

The Scrum Guide saying there's one backlog doesn't mean everything in it needs to look like a user story with a persona and a benefit statement. Technical items belong there, they just need to be framed in terms of risk and impact rather than pure engineering rationale. "Migrate database off EOL server" is a perfectly valid backlog item when it's framed as "if we don't do this by Q2 we're on unsupported infrastructure with no security patches."

The dynamic you're describing, where a dev explains why something matters and the PO prioritizes it, is actually how it's supposed to work. The PO owns priority but they can't make informed decisions without the team explaining the consequence of deferring something. That's not the team going around the PO, that's healthy collaboration. Where it breaks down is when devs frame everything as urgent or frame it in pure technical terms the PO can't evaluate.