Keeping an open mind about the value of your backlog is a useful exercise
Have you ever looked at your backlog and struggled to see the wood for the trees so to speak? Have you ever considered being ruthless and having a clear-out? That might seem like a controversial suggestion, but read on to see what some of your fellow product manager community think about it.
I engaged in a debate about this on Twitter a while back. Thread available here.
I was horrified at the very suggestion of deleting the backlog, but after reading some of the stories - I started to warm to the idea.
Most product managers out there will have a backlog that they are responsible for. It’s also true that many of those product managers will have a love-hate relationship with that backlog. Think about it – how many times have you heard these phrases:
1. Let’s add it to the backlog so we don’t forget about it
2. Is that already in the backlog?
Some backlogs (read: most backlogs) eventually become unruly and impossible for a product manager to know inside-out. These backlogs have been curated over long periods of time – usually months or even years – and record all the intentions we had for our products.
As a result, the backlog can often be confusing for stakeholders. Here are some reasons why:
1. It is a long-term care home for all potential improvementsfor the product – nothing happens to the product unless it’s in the backlog, but just being on the backlog isn’t enough to guarantee it will ever get implemented.
2. There’s rarely any sense of timeline involved in a backlog – anything not in a sprint is technically a mañana ticket;
3. There’s sometimes a lack of visibility over why items move up and down the backlog and their “rank" changesv(especially to those product managers who love a good old numeric sort on their backlogs!).
Deleting the backlog can free product managers from a mountain of mental baggage and improve productivity.
Take a good look at your backlog –
· Is it a concise list of prioritised value pieces for the next 1-3months?
· Is it a list of user stories with real consideration for improving something (anything!) for your users?
· Does it record any estimation of impact or effort?
If your answer to any of these questions is no, then it might benefit from some deleting action.
If you’re not seeing progress and are experiencing unnecessary cognitive load (read: distraction) then consider a clear-out.
“Planning and re-planning doesn't get the work done. Execution gets the work done. Execution without cognitive load is much better than execution with that load.” (source)
If you’re worried about forgetting all those really important items you discussed then know that anything that actually was important will come up again.
If you’re new to the role, or you’ve inherited a backlog for a product – then it’s a good time to take stock.
Deleting the backlog can risk losing important ideas or alienating stakeholders.
Often product managers are entrusted with maintain (read: preserving) a backlog, and are scared of potential backlash from management. There’s a strange comfort offered to management based on the size of a backlog, often with little thought given to value.
For many product managers, a backlog behaves as a reminder of ideas that have come up in meetings and discussions over time. This is not a smart use of this tool. We should all have a little more trust in the assurance that if anything is important enough, it will continue to come up time and time again.
Some teams are “attached” to their backlog – it’s been a labour of love to get it to this comprehensive state. They’ve poured over acceptance criteria and technical drawings and can’t even entertain the idea of getting rid.
Adopting a ‘lean backlog’ approach can be a great compromise.
Having considered both arguments, I will be more open to deleting items in the future. My advice is to approach with caution: for example, by archiving the old backlog for a lasting record. This will mitigate the majority of fears. That way, we have a much clearer view of the near-term future, and an easier plan for the team to follow without much deviation."
And remember: it’s a backlog, not a roadmap.