12

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?

Per Arneng
  • 2,100
  • 5
  • 21
  • 32

3 Answers3

11

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".

Ilya Kochetov
  • 17,988
  • 6
  • 44
  • 60
  • 1
    Some tasks cannot be categorized in your both mentioned groups. Some tasks are pre needed tasks like : making code-generation ready, training team members, making logging infrastructure, making the basic development infrastructure ready, separating the projects into 3 different projects to have more control over it...how to encounter them? – Mahmoud Moravej Mar 04 '12 at 09:06
2

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.

Yuval
  • 438
  • 2
  • 6
  • Can you give me an example? For example how can I explain "Making code-generation tool ready for the current project" in business terms? – Mahmoud Moravej Mar 04 '12 at 08:59
0

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.)

laalto
  • 150,114
  • 66
  • 286
  • 303
  • 5
    IMHO, the dual backlog approach is not a good practice. The team should rather try to express technical stories in business terms, to show the business value they provide, to explain how they impact the team velocity. This way, the PO will be able to prioritize them like any other stories. – Pascal Thivent Sep 09 '09 at 12:48
  • I think having more than one backlog makes the project or sprint management a nightmare. I think it is an anti-pattern. – Mahmoud Moravej Mar 04 '12 at 08:57
  • 1
    More than one backlog leaves the product owner and dev team in conflict. If there is trust between both sides then this isn't a problem. If there isn't trust you have larger issues. – Chris Jul 24 '12 at 18:55
  • Each setting/team is different; there are no rules, really. A list of improvements to make can help get stuff out of developer's heads. The items can be "worked into" estimates for user stories during planning. Larger items can be reframed into user stories but with the value clearly mapped, its the "so that" which is important; so that the page loads quicker + link to page load / sales impact studies. – Luke Puplett Sep 24 '18 at 10:47