Managing Product Development » Might Three Backlogs Be Better Than One?…

Managing Product Development » Might Three Backlogs Be Better Than One?…

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.

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?

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.

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.

Cheers,
Dave

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.

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.