How does very large technical items like containerization get prioritized by the team?

As Product Owners are accountable for maximizing value and the total cost of ownership of their product, they may need help from stakeholders and/or the developers to understand the benefits and pros/cons of such an investment.

Would it make sense to containerize a product that is end of life or on an old tech stack? Or perhaps that data shows significant savings because of less overhead or that the product could be ported to a different platforms and increase revenues. In the end we have to respect the Product Owner's decision, and good Product Owners will want to keep an open mind, rely on help from others if they are not technical, and use data to make an informed decisions.

As far as the implementation goes, rather than a big bang approach to implementing containerization, perhaps the approach uses the concept of emergent architecture, where some containerization work is done each Sprint while the team is still delivering PBIs of interest to business stakeholders.

Immediate customer or user value should not be the only criteria for ordering the Product Backlog. The Product Owner needs to understand that there are other kinds of work that are important.

One of these things is paying back technical debt. Accruing technical debt slows the team down. If the customers expect the team to regularly deliver at the same or better pace, then technical debt cannot be allowed to accrue, so spending a little bit of time to pay it back quickly may be better.

Another is technical enablement work. There may not be technical debt, but doing work now can position the team better for the future. Containerization is a good example of this since it can enable scaling of the system to handle greater loads.

In both cases, it is helpful to express the value of the work in terms of the user. Even though it is technical, why would the customer or user get value from doing it? For example, containerization can be tied to performance. If you are expecting an increase in users or load on the system, taking the time to enable scaling before performance becomes a critical issue can let you spend the time to design the solution right rather than having to hurry and get something done because customers and users are unhappy with the performance.

My rule of thumb is to always make Product Backlog Items understandable to stakeholders outside the Scrum Team. You should be able to justify everything into how it will make the product better or position the team to better serve stakeholders. If you can't do that, then you can think about if the work is really necessary.

Thanks @chris, @tomas, you're both bang on.



What I am guessing is that the developers and software managers have not been able to write the PBIs in a way the allows them to be prioritized and the PO does not understand the long term benefit.

There has been an effort from devs and managers to get the work done on the quiet and taking developers out of sprint in an effort to get some traction on the work. 

I have been trying to stop this and instead encourage the devs and managers to explain the long term benefit to the customer. It's a struggle.

Very large technical items which do not necessarily have immediate value to the user such as Containerization are very difficult to get prioritized.

How do organisations get items like this to done e.g. get it prioritized in the Product Backlog?

A requirement of such a technical nature might perhaps be a criterion of Done, rather than an item in the Product Backlog which must then be brought to it.

Developers may seek containerization to improve the quality of technical provisioning, for example. Users would be rightly oblivious to these technical choices.

The effort required to achieve an improved standard of Done should be factored into the Developers' estimates. It may then be amortised over all or part of the Product Backlog.

Any software change has two values, negative and positive.  It is negative as long as you do not make the change and positive when you do make the change. This value does not have to be monetary and in many cases it will not be. In the case of technical debt, the Developers have to help the Product Owner understand the two values. Some of the value statement could be that in order to make additional feature changes, this refactor has to occur or by refactoring the developers will be able to make new features faster.  In the case of containerization it could be that it will be easier to scale up/down production resources. This provides the end user performance and allows the company to save money during periods of lower utilization. 

After the Product Owner learns the value, they should then weigh each item against the other equally.  Remember that not all stakeholders are the users of the software.  Sometimes developers, even the ones on the team, or the stewards of the production environment are stakeholders.

I think this sounds very similar to asking how to deal with non-functional requirements in Scrum and I think they way they are handled applies here. Usually I've seen NFRs around maintainability, performance, availability, security, deployability, modularity etc set out in contractual requirements but they still have to be dealt with. 

They can be part of the Definition of Done but if they can't fit there they can be an individual Backlog item and/or could be part of the acceptance criteria in a backlog item.

I hope that helps your thinking on your situation.

Thanks Ian, Ruth. I have been thinking about how to get this included in the feature work e.g. in the DoD. I can bring it to the team. I can picture it as failing for quiet a while as the framework for this functionality is not there, alot of groundwork to do but that could be a good thing and give the devs something to think about and figure out how to bite bits off but with an real tangible end goal in sight.

I've also been thinking of how to introduce this as Innovation and risk taking, something we are missing.



Daniel, agreed that it's not all about users of the product, this has been an argument from devs for the past few months, actually a complete about turn from what was happening where the technical guys were going on technical adventures without any thought to how it might help the user. How to convince the PO that performance etc is an issue that we need to fix now over features will be a challenge.

Another thought I had on this is to find out the benefits of what is being proposed and the impact of not doing it and then explain that to the PO. Also, do you have any examples of where the initiative played out in other organisations and the benefits they reaped that you can cite? And as always, can you start small rather than big?

Also have you read The DevOps Handbook? 

Daniel, agreed that it's not all about users of the product, this has been an argument from devs for the past few months, actually a complete about turn from what was happening where the technical guys were going on technical adventures without any thought to how it might help the user. How to convince the PO that performance etc is an issue that we need to fix now over features will be a challenge.

This is something that I've noticed a lot.

My understanding of the historical origins of the Product Owner is that it is derived from Toyota's Chief Engineer role. However, in my experiences, many Product Owners don't have a comparable background to a Chief Engineer.

There are many things that are shared between the Chief Engineer and the Product Owner - acting as the voice of the customer, defining and optimizing value, maintaining the concept and vision and goals. However, the Chief Engineer is also accountable for the architecture and performance and characteristics of the system. At Toyota, the system is the model of car under development. If there are deviations from previous good standards or the current state-of-the-art, the Chief Engineer is responsible for the ramifications of those decisions. However, in my experience, there are very few Product Owners who have enough in-depth technical knowledge to own them. The Scrum framework also pushes these responsibilities away from the Product Owner and to the Developers.

I strongly recommend Morgan and Liker's The Toyota Product Development System: Integrating People, Process, and Technology. This is one of the historical origins of Scrum and focuses heavily on the engineering and product design aspects that tend to be more similar to how Scrum is applies than the manufacturing aspects covered in some other books and resources.

@ Niall Fallon @Thomas Owens I've recently got trained on agile Methodology and I was not able to do that ...Can anybody please assist me on this ...