Might Three Backlogs Be Better Than One?

I've been working with several clients on their transition to agile approaches to their projects. They all have a common state:

  • Many features to implement
  • Huge technical debt
  • Many defects

They want to get a handle on all the work they have to do.

I suggested they consider three backlogs, making sure that for a given iteration, they consciously choose what they want from each backlog so that an iteration has only one backlog, all agreed to by the product owner.

  • The PO buckets the work by features, technical debt, and defects.
  • Rank each of those buckets.
  • Now, for each iteration, the product owner chooses from the lists to create a single ranked backlog for the team.

I recommend looking at the #1 slot in each bucket. Which of these three is the real #1 for this iteration? That goes on the iteration's backlog. Now, the next one from that bucket pops up and you only have three things to compare again.

One of the problems each of these organizations has is that their technical debt and defects were invisible to the decision-makers. Now the technical staff and the project managers have a list that is is visible to the product owner/customer. None of the work is secret—it's all out in the open. They can discuss, poke, prod, ask, and negotiate to a reasonable conclusion.

It's too early to tell if this will work for them. But the value of the three backlogs is that they can look across all the potential work in the organization and make a conscious choice for now. That choice doesn't have to be permanent. Because they are working in backlogs, they have a shot at making decisions and adapting their choices later.

24 thoughts on “Might Three Backlogs Be Better Than One?”

  1. “…they bucket the work by features, technical debt, and defects.”

    Maybe that would work. Something about it raises an alarm in the back of my mind, though. Not sure exactly how to express my worry here, but it has something to do with the fact that work items are categorized by type of work rather than by which workstream or value stream they support.

    “None of the work is secret–it’s all out in the open. They can discuss, poke, prod, ask, and negotiate to a reasonable conclusion.”

    Since the technical debt was invisible to stakeholders previously, this surely must be a step forward.

    What about identifying the workflows in the organization; can we call them “value streams,” or is that abuse of the term? Not sure. Anyway, if there are distinct workflows that deliver different value or deliver value to different communities in the organization or different external customer bases, I wonder if /that/ would be the way to align the backlogs with the business. Each backlog then would contain new work and defect fixes, to be prioritized against each other as appropriate.

    As far as accumulated technical debt is concerned, is it feasible to address it incrementally in the process of delivering the other work items? Given the history, would that make the technical debt “invisible” to stakeholders, or can they understand that some work items will take longer to deliver than they might normally expect because technical teams intend to pay down the debt? This level of understanding may vary from one organization to another, and may compel a certain way of structuring the backlogs. Obviously I can’t tell from where I’m sitting. Even so, the backlog structure you describe sounds a bit “funny” to me.

  2. Thanks for the post Johanna. I worked with a customer that had three backlogs – product backlog, defect backlog, and the sprint backlog. This worked well for them as they were also shooting for target percentages of new features, updates, and bug fixes in each sprint.

  3. I must be way out of step with agile thinking.

    Re Robert’s comment:

    1. I thought the sprint backlog was a subset of the product backlog – the bit the team had committed to delivering in the current sprint. Is it a different backlog?

    2. What’s the advantage in aiming for a percentage of bug fixes per sprint, versus prioritizing all work items (features and bug fixes) per business value? I’m not seeing it intuitively, so please explain how it’s better.


  4. I like the approach David describes. The technical debt backlog served the purpose of raising awareness of the issue, but didn’t become a permanent feature of the organization’s workflow.

    I took a different approach to technical debt on a recent engagement. Meeting with stakeholders and the technical team, I explained the business impact of technical debt, and the team explained that they intended to pay down technical debt whenever a customer request touched legacy code. They made it clear this would cause lead times to increase for customer requests. The customers grumbled but accepted this provisionally.

    After about two months, customers were becoming impatient about lead times. Around that time, some of their requests concerned code that had been refactored. They had the opportunity to experience the difference. The refactored code could be modified 4 to 5 times faster than the legacy code. At that point, the customers were all in favor of continuing the practice of incremental refactoring.

    Furthermore, based on this experience, the customers were well equipped to negotiate some stories to incur technical debt intentionally, when there was a true business need to push a modification into production quickly. They understood the trade-offs and could make rational choices.

    The point in that story is that the problem isn’t “how many backlogs?” but rather some other problem – technical debt, or (as Bob related on Facebook) build times, or what-have-you. There may be more than one possible solution to any given problem. It may not be necessary to complicate the backlog structure to address some of these problems.

    Unfortunately, this discussion has become bifurcated between this blog and the Facebook entry. I suggest we continue here, on this blog, if people still want to talk about it.

  5. Hi Mike,

    “…share the team’s velocity for a sprint i.e. we will spend 50% on new features and 50% on defects.”

    So, if the team finishes with the defects in 20% of the time, what do they do with the free 30%? Play video games? Have a party? I’d like to work there!

    Isn’t splitting time in that way rather arbitrary? (You said split velocity, I said split time; rationale FWIW: Velocity is an empirical observation, not a target.)

    Anyway, why not address the highest priority work items first, be they features or be they defects?

  6. I am not a great fan of having technical debt on a backlog. It implies you can work on it independently of any user-value story, which I am no convinced is a good idea (which I actually think is usually a bad idea). It also undermines trust to some extent. As a development team we need stakeholders to trust that we are (now) going to deliver high quality product, and that requires a reduction of technical debt. We build that work into our story estimate. Stakeholders need not worry about the “how” they just need to be better focussed on the “what”.

    As for bugs… Bugs are just another form of user story, they are not different and there is no benefit in treating them so. A user-value story is “something the system doesn’t do that we’d like it to do”. That applies to both defects and new features.

    I think having three backlogs adds unnecessary complication to a simple process. It sounds clever in theory, but in practice I think there will be additional overhead, and confusion.

    To Dave’s point on sprint backlog, absolutely yes, it is a subset of the product backlog (sometimes with the contained items broken down into a to-do list).

  7. The only time I have used this approach is when there has been a need for a decision on how we share the team’s velocity for a sprint i.e. we will spend 50% on new features and 50% on defects.

    It sounds like this is a little different because the ‘new features’ bucket is across products and thus not a ‘product backlog’ per se.

    Not convinced that the categorisation of work in this way helps such work get done faster or better. But introduces more overhead in picking what is to be built. This overhead may be necessary if there are real problems otherwise.



  8. Johanna, thanks for triggering an interesting conversation.

    I have used separate backlogs for technical debt and new features with a team that feared forgetting to resolve technical debts. It was a transient solution that exposed technical debt to stake-holders and served to initiate conversations about the benefits of building new features against resolving technical debts.

    Certainly in this case there was no value in comparing value of a technical debt item with the top item on the backlog. Rather, we selected technical debts that could be addressed as a complement to the feature being built. For example, we can fix this issue while building that feature, it’ll slow down the building of the feature but place us better with respect to future development.

  9. “It was a transient solution…we selected technical debts that could be addressed as a complement to the feature being built.”

    David’s approach makes a lot of sense to me. The removing of technical debt should always be aligned with building new value, and the approach being transient is very important: get stakeholders back focusing on the “what”. But perhaps letting them look at the mess early on allows them to have the trust required.

  10. This sounds like make-work to me. Should defects not be considered first-class citizens from a prioritization & planning perspective and therefore be part of the same backlog? If separated out into a different backlog one runs the risk of disturbing the relative prioritization against each other. In particular if one chooses to use percentages of each the whole idea of prioritizing based on business value is thrown out the window. If using a tool (like VersionOne)or using a backup to story cards (like excel) one could just then sort based on defect/feature/etc. Philippe Kruchten gave a good talk at Agile Vancouver titled “What colour is your backlog” which can be seen at http://tinyurl.com/BackLogColour. This directly addresses both “visible” and “invisible” elements of any given backlog like features, defects, technical debt and architecture.

  11. Johanna, here’s an alternative approach to the sort of problem you describe:

    * Many features to implement
    * Huge technical debt
    * Many defects

    What if, instead of trying to capture everything that’s been piling up on the corporate “to do” list in one or more backlogs, we suggest that they delete the backlog? What might happen?

    When I’ve suggested this, the initial gut reaction has always been visceral fear followed by nervous laughter. After some explanation, the worries subside.

    A clean slate sometimes works (I won’t say ‘always’) like this:

    * Many features to implement

    “But, we’ve had this feature on our ‘to do’ list for three years! It must be terribly important by now!”

    Is it, really? Or is it just burning a hole in your pocket, like a wad of unspent cash?

    I’ve said this in reply: “If that item has not been implemented in the past three years, and the company is still in business and making money, how important could it possibly be?”

    Usually there isn’t time to implement all the features everyone has dreamed up over the past n years, no matter /how/ you structure the backlog(s). After clearing the old backlog, anything that’s really important to the business will pop up again. Most of the stuff will just be forgotten, though (in many cases).

    * Huge technical debt

    The rule of thumb here is “If it ain’t broke, don’t fix it.” Parts of the codebase that don’t have any open production support tickets and aren’t affected by any work in process don’t have to be remediated. If and when a team needs to touch those parts of the code, they can refactor it at that time. The accumulated technical debt doesn’t have to be seen as a massive ‘to do’ item in its own right.

    * Many defects

    “But we have 7,500 defects in our bug tracker!” Really? And you’re still able to do business? Most of them must be pretty minor, then. Might be more cost effective to leave them alone than to try and fix them all.

    Defects that are affecting business operations have to be included in the new, shorter backlog(s) for obvious reasons. Every reported defect doesn’t necessarily have to be fixed. Most of them are probably trivial.

    For context: Last I heard, there were over 150 known bugs in Microsoft Office. Yet, millions of people worldwide use the product every day and are quite satisfied with it. The mere /existence/ of a reported defect doesn’t automatically make it an important work item.

    Just food for thought. YMMV.

  12. It’s enough to have reasonable person as a Product Owner, product manager or whatever you call the person being the main driver for setting priorities for the next version.

    Then feedback from the team (e.g. on technical debt) is treated as the same source as customers’ requests. Then one can weigh importance of not only feature requests but also tasks which reduce technical debt or specific bugs. After all it’s all some kind of compromise.

    On the other hand I don’t believe 3 backlogs would change situation much if product manager forces new features only. It will be just another unused practice.

    If there’s will there’s a way as one of my partners used to say. On the other hand if there isn’t will no tool will help.

  13. @Dave: some further explanation.

    1. The approach of multiple backlogs worked for the company I was working with. Due to the tool they used it was easier for them to see the num of defects in a separate backlog rather than having them as part of the main product backlog.

    2. Everything was prioritized according to business value as well as other priorities (severity of the bug, clients affected, etc.). Again, it was easier to see everything in separate backlogs rather than one ginormous one.

    Essentially it came down to team and business preference on how to set up their systems. Just because they weren’t doing it “by the book” doesn’t mean they weren’t following Agile principles.

  14. Hi Robert,

    If what you did worked in the situation you were in, then that’s great. I don’t care about the number of backlogs or about following any book in a knee-jerk cookbook way. I care about delivering value and continuous improvement. There are many ways to do so.

    If an organization supports more than one value stream, then I think it makes sense (in the general case) to have one backlog per value stream. I don’t think anyone involved in this discussion has suggested that every organization must have exactly one backlog, period. The disagreement has been about the /content/ of the backlogs: whether they should contain specific types of work items, like /only/ new features or /only/ defects. I’ve found that the most workable way is to include both new features and reported defects in the same backlog.

    Now, we might have to deviate from this model for practical reasons. A couple of people here have said that they separated out the defects in order to make them more visible to management. That sounds like a valid reason to me. There’s nothing wrong with that as a means to an end.

    However, there /is/ something wrong with mistaking that sort of tactical workaround with a real solution to the true root causes of problems. Specifically, the thing that’s wrong with it is that we can become complacent and forget to keep practicing continuous improvement.

    I don’t see the value in splitting a backlog just because it’s “ginormous.” We’re only concerned with the handful of highest-priority items at any given time, plus a near-to-medium term buffer of upcoming work. Whether there are 5 items or 5 trillion items still remaining on the backlog, it just doesn’t matter. The size of the remaining backlog doesn’t have any effect on teams’ short-term planning.

    When faced with a “ginormous” backlog, the first question that comes to my mind is: “Why is the backlog ginormous?”

    Rather than just attempting to tackle it as-is, I want to understand how the backlog got to be so long in the first place. Chances are it’s not a valid backlog.

    Did they do too much up-front analysis and generate a WBS, which they’re now calling a “backlog” because the term “backlog” is fashionable?

    Did the backlog gradually grow in size, like a tumor, because they didn’t groom it?

    Is there some other reason?

    I’ll bet that more often than not, the majority of items on those “ginormous” corporate backlogs aren’t necessary at all. Don’t we really want to identify and address the most important work items for delivering business value? Do we really care about 5 trillion useless items on a backlog-that-isn’t-a-proper-backlog-because-it’s-too-big-to-make-sense-to-anyone?

    Preferences are preferences, but some ways of doing things are objectively more effective than others. People can learn better ways to work, and change their preferences accordingly. We can help them do so, but only if we recognize short-term workarounds for what they are, and we don’t mistake them for real solutions to the true root causes of problems.


  15. Hi Dave,

    Thanks for the response. The team that I was working with did do regular backlog grooming, on all backlogs in question. If they had an idea, they put it into the backlog. Later they would go through and see if there was any true value and if not, remove it. Otherwise it stayed and came back up in conversations.

    This company had a product they were developing, and they also did custom work for clients, both relating to the product and otherwise. Defects could come up in either of these three cases, and all went into the defect backlog. New feature requests and enhancements went into the product backlog. I won’t get into detail of how everything was labeled to keep track of all this, however they were able to see what was reported by who (client or internal). This system was in place before I got there, and remains today, a month later.

    Ultimately this company was balancing various priorities, and having their tools set up as they did allowed them to balance these priorities. As it was, moving to something different wasn’t in the cards, so we worked with what we had in place, which worked very effectively for them.

    It’s hard to get into the full context of this company in a number of comments, however I can say that the backlog was quite valid, and root causes were addressed.

    Thanks for all of your feedback.

  16. I like this idea and can see the benefit using lo-tech but we have struggled with this due to the “tool” mindset here.

    For now we have our technical debt stories in the same backlog as our user stories and we give the PO the opportunity to prioritize the technical debt items against stories with business value. Well, reducing technical debt does have business value, we just make sure the PO gets the final say.

    How have they found backlog management so far?

  17. Thierry Thelliez

    In the context of a small company here, we have 4 sources of work:
    1- New features
    2- Bugs
    3- Infrastructure (we are hosting applications)
    4- Technical debt.

    I gave it a try to move from one backlog to two. This did not work.

    While we are doing a decent job at prioritizing in one backlog, technical debt and other ‘under the hood’ work is just too hard to constanly argue about.

    Including technical debt work in a given task delivery is easier.

    It is still tempting to postpone the technical debt work. But it really is like being able to say ‘no’ (hey you coached me on that).

    Curiously, we are struggling balancing several parallel projects. But that’s another topic.

  18. Pingback: pligg.com

  19. Pingback: Anonymous

  20. Pingback: To have success, know why it was a success | Software Development with Linux

  21. I have introduced the idea of a “technical debt” backlog, separate from other backlogs, and (early days yet!) the idea seems to be gaining traction.

    Not to split hairs, though (especially as I have few remaining!), I see two kinds of technical debt:

    #1 (Easy). Tech debt that relates to stories in the feature or bug backlogs. These are easy to explain to the product owner, and often will fit in with the success stories that others have written about above, where some grumbling and time spent now gives returns in faster new features & custom work later.

    #2 (Hard). Tech debt that is more cross-cutting. Things like quality of tests, overall code coverage percentage, mixing of view & model layers. Yes, many of these can and should be fixed in the #1 cases above. But some of them do not. And even the most caring product owner is, for GOOD reasons, going to find it hard to care about them.

    This is where I think a truly company-wide (or platform wide, or whatever the layer above the individual agile/scrum/whatever teams is) tech debt backlog DOES make sense. And where I think each time should allocate some time each sprint to biting off some part of the company-wide carcass, and chewing it down.

    It’s company-wide tax, if you will, for the cases where the technical DEBTOR is not easily identified. Because if the tax is not paid, the interest will inevitably increase.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: