Does the Product Owner own automation type work?

The team is responsible for ensuring technical debt is addressed and burned down before it becomes unmanageable and requires a 'hardening sprint'. A new testing framework is absolutely a priority and a certain amount of the sprint should be set aside for technical (non-functional) tasks. Another, better way, is to make building automated testing - working toward that new framework - part of your definition of done and include subtasks with each story to incrementally work toward that goal. Don't forget maintaining automated tests!

The automation work you've mentioned is an example of technical debt. An excellent way to repay known technical debt is to make debt payments while performing customer-valuable work. So your tester was right. It's a good idea to align the "automation work" with customer-valuable work that the Product Owner can properly prioritize. If you can’t do it, for some reasons, allocate a certain % of capacity in your next sprint for "the automation work" and place it in the sprint backlog as work for this sprint.

> Shouldn't he just be focused on product features?

Nope, he should be focused on product value. If automation improves that value then strictly speaking he ought to care about it, and be able to make a prioritization decision.

Ian+

Development team should be able to explain to PO that by re-paying the Technical Debt (e.g. automation tests) what benefit/value product is going to have in future Sprints - may be more business value per Sprint, lesser defects and happy customer

I think there is a problem with those last two answers because the dev team should be deciding how to translate a product backlog item into deliverable product and that includes all aspects of testing. Allowing the PO to prioritise/deprioritise automation testing means he or she can decide "we haven't got time for that" - even if you've tried to explain the value. So the first answer is better in my view as the decision on testing approach is with the dev team .

> Allowing the PO to prioritise/deprioritise automation testing means
> he or she can decide "we haven't got time for that" - even if you've tried
> to explain the value.

Yes, and the PO is entitled to do exactly that, as long as it is a value-based consideration. The PO is accountable for product value and everyone must respect his or her decisions on that matter.

The Development Team *would* be in a position to insist on automation if it was a matter of quality rather than value, for example if they could no longer meet the Definition of Done without it. Automation would then no longer belong on the Product Backlog, but may nevertheless be work the team would plan to do to meet each Sprint Goal. The PO could not override that decision, as the Development Team are wholly accountable for how they turn work into a release-quality increment and any professional standards they might observe.