Scrum: Technical items in a backlog that is managed by a non technical PO? [closed]

Question

Should technical items such as "Upgrade sever from v1 to v2" or "Increase startup performance" or "Refactor login module to reduce code complexity" go in to the product backlog and if so how should a non technical product owner be able to prioritize them v.s other more functional backlog items?

Should there be a separate backlog for technical stuff? Should we have a joint PO role with two persons that could prioritize functional and technical stuff on the product backlog?

Answer 1

I have had success with the dual backlog approach:

1. Product backlog is owned by the product owner. It contains story-level items (features) that get estimated by the team and then prioritized by the product owner. This estimation process splits the stories in smaller tasks.

2. Team backlog is owned by the development team. It contains task-level items that are relatively small (can be completed within a sprint). They can be linked to stories for example as impediments: to complete the story, the following technical tasks have to be completed first. They can also be independent so that they are not required for any story per se but they pay back some technical debt to enable higher velocity in the future.

(On some large, multi-project programs I've also had program backlogs that contain epic-level items, owned and prioritized by a program management team, to be split to stories into product backlogs further on.)

Answer 2

Usually in the 'vanilla' SCRUM the technical tasks you mentioned will not go as separate stories.

To me the non-technical PO should not be looking at the stories like 'Upgrade the server'. It's not a business story, it is not visible to the end-user so it is difficult to prioritize if it is formulated this way. Priorities should be assigned according to the business value of the work. 'Upgrading' does not mean much. 'Allowing more simultaneous connections', 'Reducing the downtime' or even 'improving the team velocity' might provide much more valuable insight to a non-technical person. If you cannot find a non-technical description ask yourself a question about the necessity of the upgrade :)

The 'refactoring' story is even more complicated. Did you ask yourself why is it a story at all? Refactoring could be done as a task in the story but it is rarely a story on itself. So if you want to make login work better or provide more features that's a story but tinkering under the hood does not count as one. Please also note that refactoring without a business purpose could easily lead to a so-called 'gold plating'

I would suggest doing the 'upgrade' stories as a spike with the 'improve performance' and 're-factor' being the tasks for a relevant business story.

P.S. You might find a good discussion on this topic (mostly in part 3 of it) in the excellent book by Mike Cohn called "User Stories Applied: For Agile Software Development".

Answer 3

I agree with the view of looking at the business benefit of any technical story and tracking it on the main product backlog

I do think that there are internal stories related to the velocity/capability of the team, which are sometimes more conveniently managed by assigning some capacity to the developers, especially when the Product Owner is not interested to prioritize or manage those stories. E.g. assign 10% capacity to test automation backlog (of legacy regression), CI server setup, etc.

Yes, everything can certainly be expressed in business terms, but some of it should be considered "the way we need to do our job" where there is trust between Product Owner and team that the team will make best use of the capacity assigned for this.