In Scrum, should you split up the backlog in a functional backlog and a technical backlog or not?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

I agree with MelR. If there is anything that is 'technical', we need to look at why we are doing it - or even what's the short and long term cause and effect (to the user)?.

I have seen many backlogs where the so called 'technical tasks' can easily be written in a business value kind of way.

Technical tasks are also often the result of large broken down stories as it can be the easier way to break things down. But this can cause slower iterations of true added value (or feedback opportunities) or even worse the failure of sprints.

In regards to "code that erodes and should be refactored" as Patrick mentions I believe we we need to ask - which area of the system functionality is that code affecting? and what's the long term effect on the user if we don't refactor it now?

Then there's the subject of "leaving things slightly better than how we found it" so as to reduce long term technical debt and and can this be done as part of the small stories in each sprint without too much impact on the wider project?

Ultimately I don't see the need for two backlogs this opens up opportunity to slow down properly prioritised needs - but there's a need for a product owner who is educated in the concerns of the technical impacts and has a strong ability to identify true value so to break down stories vertically - Adobe offer a good explanation on vertical slicing.

Answer 7

No you should never create technical stories. This is an common error. You stories must reflect the business requirement. Technical stuff is never really from business requirement. This is the role of the scrum master and the team to evaluate all technical task they will have to do to reach the objective or the story.

If your story is about creating a login screen for example you will have to consider the creation of the database also if not yet created.

I don't see the problem to create, with the PO, tasks where IT team is the user. If the task can be understood by the PO and can be evaluated in term of business value then yes you have a way to create kind of technical stories. You just use the system.