Does Your Backlog Suck? Kanban Can Help
Agile backlogs can be both a blessing and a curse. On the one hand we have a list of things we need to do that is ever-evolving. It is potentially estimated and may have detail where required for the next few stories. It is possibly prioritised. On the other hand having something on a backlog can set the expectation that it’s going to be delivered.
Managing large backlogs often creates a huge amount of waste in the form of continual re-prioritising, updating stakeholders who have an interest in the backlog, and estimation for the Scrum teams etc.
The misunderstanding that things on the backlog will be delivered comes from a few places:
- Team members and product owners saying things to stakeholders or users like ‘don’t worry it’s on the backlog’, ‘great idea, we will put it on the backlog’, ‘we have that suggestion on our backlog’ etc
- Providing an idea to a Product Owner or team member, who puts it on the backlog with no explanation of what might happen to it
- Typically no one explains that there are already an unmanageable number of items on the backlog. Often the work isn’t done to figure out how much work is required to complete an item or what are the chances of it ever being completed. Additionally some items can sit on a backlog for months or even years.
How you can make it better?
Deferred commitment means we don’t commit to doing something until it’s in ‘ready’ or ‘committed’ on the Kanban board. The idea is to make this explicitly clear to stakeholders when they request something. We invite them to the replenishment meetings where we update or replenish the ready / committed queue. These stakeholders could be the Product Owner or multiple stakeholders all with their own requirements.
Above is an example of Upstream Kanban flowing into delivery
Upstream (or discovery) Kanban
This can also be a good option for setting expectations and encouraging stakeholders / customers to put forward their ideas. Here we are also explicit that these ideas need to be triaged through the upstream / discovery process. We set up our upstream Kanban System to filter the ideas using criteria such as:
- Does it meet our business objectives?
- Does it fit in with our product roadmap?
- Do we have the money to deliver this?
- Are we comfortable with the risk associated with delivering this?
Our intention is to discard items as early as possible and ensure only the items that deliver real value to the organisation get committed to. The cost to an organisation for delivering work is usually higher than it is to decide what to do. Therefore, discarding and deferring ideas not only creates transparency but it can significantly reduce cost by delivering those items with the highest value rather than those that have been on the ‘backlog’ for a long time.
Is upstream Kanban explicitly for use with Kanban delivery teams?
Absolutely not, my experience has also been to implement this in a number of different scenarios, with:
- Scrum teams
- Product Owners
- Business units trying to work out what they want to do and how to set priorities
- Individual teams and multiple teams working on the same product / project
- Portfolio / Program Management Offices.
However, Kanban discovery and delivery teams working with the concept of deferred commitment often get the best of both worlds. These teams are set up with the concept of delivering a service and therefore have a greater focus on what they are aiming to achieve.
In conclusion, backlogs need not be heavy, cumbersome artifacts. Make the process of taking ideas, triaging them, discarding or deferring items, and how you work through them visible. After all, transparency, inspecting and adapting are at the very heart of Agile.
Tags: Kanban, Backlog.