If you are wondering “How to deal with a very large product backlog” you are probably in one of the following scenarios.
- You just started a new job and inherited the backlog from the previous Product Owner (who moved to another position or company).
- You changed team and product in the same organization (so you inherited backlog with the product, ideally more demanding one).
- You made backlog enormously big yourself and at some point, you noticed it and decided to deal with it.
In any case, you are facing a very large list of more or less well-described stories and bugs. Some of them are fairly new when others are years old. I am going to give you three simple procedures that will help you get rid of such a problem. Which one is best? Read to the end and you will soon find out!
Procedure: “Delegate the hard work”.
I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it. – Bill Gates
Instead of proactively digging through a pile of issues yourself, you should delegate work to original reporters (people who initiated stories). How to do that you’ll ask. Simply close all issues with elaborative comment and underline that you need their (reporters) help. Ask them to respond if the matter of request is really crucial and still unresolved. Later on, reopen only issues to which anyone responds. Believe me, people mostly won’t respond, because:
- They already found a workaround for their problems.
- They already forget what they wanted.
- They don’t value reported issue high enough to waste their time explaining it to you.
- They already changed their job.
Seriously, this procedure is really powerful and most importantly it is transparent. You are not hiding the problem. You are actually asking for help. A very important skill for the new Product Owner.
Commonly people instead of closing issues use some kind of a label or special filter. Common names are “Graveyard”, “Parking” or “Hidden” backlog. I highly NOT recommend that approach because it will make your life harder. In the future, you will always have to remember that special filter or subquery.
Procedure: “Dominate the large product backlog”.
Get it through your head. First impressions last. You start behind the eight ball, you’ll never get in front. – Harvey
This one is very simple in explaining. Make no excuses. Work all the hours that God sends you. Go through every single issue and make a decision – is it valuable or not? Remember that you are not alone, so:
- If you have a question – ask.
- If you don’t understand – paraphrase.
- If you don’t agree with the reporter – question his point.
You are going to do what everyone else (or you) was avoiding for such a long time. You are going to take complete ownership of the existing backlog. You will know about every single issue that is not yet resolved in your product. Such an approach has one big pro – it will give you a huge boost in self-confidence. There are also three main cons here – it consumes time, time and time.
Before you go… remember that backlog is not the only thing you should take care of when you start. You also need to meet with stakeholders, you need to prepare a roadmap and plan the next sprints. In the meantime – make a quick benchmark to the market. Better cancel all your evening plans to the end of the month if you are going to use the “Dominate” procedure.
Procedure: “Kill it before it lays eggs”.
I could have killed them all.
Very simple yet powerful technique but requires guts to do. Select all issues in the task management tool you have and… delete them. Act like the issues you deleted never exist. So when you are using JIRA for instance, make sure to disable sending email on a bulk delete. Reason for doing so is accepting that you will probably spend an enormous amount of time digging through the whole stack, just to find out that half of the issues are obsolete, a quarter is incomplete and only a couple are valuable.
There are many better things to do! For instance:
- Talk with the users and ask them, what they miss most.
- Talk with the stakeholders (use some facilitating technique) and ask them what they think, should be done first.
- Integrate with a new development team and ask them what they think, should be resolved first (probably from a technical point of view).
- Get fluent with a new product.
After a couple of meetings with all those people, you will have a new list of top priority topics. Use them to prepare a brand new backlog and this one… keep it short.
Which procedure should you pick to deal with the large product backlog?
I can’t tell you what you should do. I can tell what I’ve done many times. From my experience, the best approach is mixing all three procedures. Make a quick look at your new backlog and define your own borderlines. For instance:
- Delete all issues older than 1 year.
- Close and comment on all issues older than 1 month and younger than 1 year.
- Get familiar with all new issues.
This is just my point of view. I am really curious what is your idea here? Are you Bill Gates, Harvey Specter or Rambo type of guy?
Beyond many articles, I’ve read on this topic one is really important for me and needs a link. It’s Mike Cohn’s blog post.