Thanks for sharing your approach George.

I am in a pretty much the same situation as a PO.

What helps a lot is long-term planning, so that the topics for a sprint stay coherent. My goal is always to work on one or two components at the time, and to cover both bug fixes and new features. This reduces the context switching that is otherwise exhausting, both for team and for PO, and speeds up the whole development process.

This plan can be interrupted when blocker bugs occur, that have to be tackled immediately. Here comes another task for the PO: adequate priorisation of what is a blocker and what can wait, so that sprints can still remain coherent for most of the time. True blockers are solved immediately, the rest remains in backlog.

In the begining, the stakeholders may be against this, but they can be convinced in favor of it: it is much better for users to have a whole feature once in several months, than to get incomplete pieces of it every 2-3 weeks.

Thanks for sharing your question Andrea. In situations like yours, I recommend experimenting with a Kanban-based process. Please take a look at my articles “Is Scrum Right for Your Product?” and “Succeeding with Innovation and Maintenance“.