Menu
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?
546
It is entirely possible for a Product Backlog to be empty, but that does not mean it has ended. Usually, this is just an indication that bugs have not been logged yet, or the product owner is doing a poor job of planning for additional features.
In the absence of a Product Owner, there will be team clashes hence dip in performance of the team. 2. Understanding the product backlog priority and planning sprint will be affected.
A Product Backlog Item (PBI) is a single element of work that exists in the product backlog. PBIs can include user stories, epics, specifications, bugs, or change requirements. The Product Owner of an Agile team compiles and prioritizes the product backlog, putting the most urgent or important PBIs at the top.
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".
197
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
