Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In our Scrum teams we use a backlog, which mostly contains functional topics, but also sometimes contains technical topics. The advantage of having 1 backlog is that it becomes easy to choose the topics for the next sprint, but I have some questions:

  • First, to me it seems more logical to have a separate technical backlog, where developers themselves can add pure technical items, like: we could improve performance in this method, this class lacks some technical documentation, ... By having one backlog, all developers always have to pass via the product owner to have their topics added to the backlog, which seems additional, unnecessary work for the product owner.
  • Second, if you have a product owner that only focuses on the pure-functional items, the pure-technical items (like missing technical documentation, code that erodes and should be refactored, classes that always give problems during debugging because they don't have a stable foundation and should be refactored, ...) always end up at the end of the list because "they don't serve the customer directly". By having a separate technical backlog, and time reserved in every sprint for these pure technical items, we can improve the applications functionally, but also keep them healthy inside.

What is the best approach? One backlog or two?

share|improve this question
add comment

5 Answers

up vote 14 down vote accepted

I'm no expert but I'd say you can only have one backlog per team. The team needs to decide which issues are urgent and which ones can be postponed. If you separate the issues into separate types of stacks you go against the core idea that is at the heart of scrum, which is that there is a pool of issues and each sprint the team works on the most urgent of them. If you (sub)divide the teams you might be able to divide the types of tasks which are relevant to them, but you'd basically be setting up teams which work in parallel. Urgency/necessity is the number one decider when it comes to planning the next sprint. You may categorize the tasks, but this shouldn't get in the way of your decision process.

share|improve this answer
add comment

I concur with all answers above. In the heat of commercial reality, the PO will keep on prioritizing functional stories over technical ones. Often to the frustration of the team. The team should refrain from technical stories without any user value (who cares about an optimisation, if speed is not an issue?) and learn to see certain other technical tasks as implied by the functional stories. The "definition of done" also plays a big role. The remaining functional stories go on the backlog for the PO to prioritize.

E.g. Technical documentation: Availability of technical documentation (where applicable) is a typical item that belongs in the D.O.D. And therefor, updating it is IMPLIED with every functional story.

E.g. Refactoring code: should be done when it benefits the product development. Not earlier (the team should not assume in what direction the product will evolve) and not later when it has already turned into technical debt. Having the design reviewed could also be part of the DoD.

share|improve this answer
add comment

I'd like to add my voice to those who recommend one backlog per product. Creating another backlog is a rational response, but is really just avoiding the core issue: Why won't the Product Owner prioritise technical items over feature items? You should focus on solving this rather than working around it. You could use the 5 Whys technique, for example, to try to get to the bottom of things.

There could be many reasons why the PO doesn't prioritise technical issues. For example, maybe the tech team isn't explaining the long-term cost (in $$$) of not addressing the technical debt. Maybe it's something else completely. There's a good chance it's down to a communication issue, and the long-term solution is to work on it and resolve it -- remove the impediment.

Additionally, I have an another question for you to think about: Why has the technical debt arisen in the first place? Ideally work such as refactoring etc. should happen within the functional stories and be completed within the sprint. They shouldn't be extra stories in their own right otherwise you don't have potentially shippable code.

share|improve this answer
add comment

I agree with Onno in that there should be only one single backlog per project. Otherwise, the team is basically taking in their own hands some decisions which rightfully belong to the product owner.

Even "purely technical" items must have some practical value for users (and therefore for the product owner) to be eligible for the sprint backlog. It is your task to explain the benefit of these to the product owner, and to convince him/her of the added value which justifies the cost. And this process forces you yourself to think through these issues and select the technical changes which bring the most value to the project with the least effort.

share|improve this answer
add comment

What you're referring to is commonly called 'technical debt'. It can sometimes be difficult to see how technical debt work fits into the scrum process, in the same way that defects can.

What you are proposing is similar to suggesting that there be a separate 'defect backlog' as well, splitting the backlog into 3.

Personally, I would not advocate splitting the product backlog at all. The idea of the product backlog is to represent outstanding items of work. From that perspective, the only difference between a feature and a technical debt item is that the requirement came from the development team, not from the customer. It is still an item of work and it still needs to be managed, including prioritizing it against other items of work. This is especially true if the technical debt item requires testing, in which case it should go through exactly the same QA process as a regular feature.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.