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.