Backlogs suck – but they dont have to.

An often-mystical beast of never-ending unorganised work that never shrinks. Everything in Agile is driven by a backlog of some description. We talk about ensuring PBIs are INVESTable, and DEEP, but I find myself in projects these days where the backlog is just a noose around the teams neck. Teams shy away from it. Its acknowledged but never spoken of. It’s used as an excuse – you know the one. It never shrinks, it’s never updated, and as time goes on its value decreases.

Spicy huh! Agile delivery guy critizing the backlog!

I’m not against the backlog par-se. Of course not. A backlog done well can be a beautiful thing. It’s just a list of tasks though. A list of tasks is a good thing. I use lists of tasks every day. You should too. It helps with getting stuff done. But what I’m often seeing is massive un-touched unloved backlogs spanning into hundreds of PBIs going over months which in effect, exist to make the delivery manager, project manager or product owner feel better merely by its existence. It’s like the backlog is now the modern-day replacement to the Gantt chart. Remember that thing? That often aged colourful asset put on a wall which was whimsically optimistic at best, everyone swarmed around it, it made management feel soft fuzzy and safe but it was way more PR than it was a plan set in reality.

In Agile, we worked against that false sense of safety that an asset such as a Gantt offered for quite some time, but all we’ve done, all organisations have done, is replace the Gantt chart with a stuffed to-the-brim backlog. If I could count the amount of times I’ve helicoptered into a project, rappelled into the trenches, took a look at the backlog and thought ‘nah, that’s a *****ing nightmare’.

Each day, teams kidding themselves as they attend the stand up, blindly referring to tickets that haven’t been touched in days, sometimes weeks. Still referring to them though just to often appease the delivery person. Delivery managers kidding themselves that PBI quantity equals planning detail.

Sound familiar?

In this post I wanted to explore how I like to model and convince teams and businesses to model, their own backlogs. I’m not an entire expert, heck not even an aficionado, but this is what I’ve learnt, seen and what I do.

How I think a backlog ‘should’ be used and how it ‘should’ work

I think what a backlog can be, is a useful tool for negotiation. Instead of saying ‘no’ to a feature, it’s easier to explain that any request can be put into a backlog and prioritised accordingly. I’ve often used the backlog (rightly or wrongly) as a buffer between my stakeholders and the team to help take the pressure off. Almost using it as a strategic tool more than anything else. I think a well estimated and controlled backlog is a great way to visualise WIP too for teams. But they are almost separate things. I’d expect a Product owner for example, to have a much simpler feature-driven backlog devoid of much detail outside of key features and outcomes. A good product owner needs to be ruthless when it comes to prioritisation. They often aren’t. A long backlog is often a sign this is not happening.   Its worth remembering that considering a lot of tasks in the backlog never get done, a big backlog increases the cycle time & subsequent waste creation – that’s expensive.

Whereas an engineering team may have more of a plan-based backlog demonstrating an exercise in constraint. It shouldn’t span into the next decade. Often, the next week or two will do. You just can’t plan the future

A backlog to me in its simplest terms is pretty much;

• Reasonably sized and details stories to give the team a good idea of what needs to be done and why
• Enough detail (just enough without solutionising) to get to an endpoint, or a goal.
• Some kind of release milestone dates
• Some kind of scale/ranking/prioritisation to indicate business value.

Now I’m obviously talking about software engineering projects here, but you could apply this to anything I suppose that contains a backlog.

why I think backlogs can sometimes be a bit….meh

If you know me, you’ll know I talk a lot of LEAN. I’ve had a bit of success with LEAN. The backlog, creation management and synthesis of it often gets in the way of productivity and value. I mean, you can spend more time maintaining a backlog than you can by actually doing the thing. I think a good delivery person knows when to flex and adjust the need for a backlog and knows when to ignore it. Otherwise, you’re WASTING EFFORT in the management of a project component that has diminishing value. A factory producing cars before they are sold aren’t producing cars. They are producing waste. You can see that waste. Physical unsold cars. You can’t see as easily digital waste, like a backlog for example.

What I try and do in projects to make the backlog more meaningful

The presentation of the Increment is intended to elicit feedback and foster collaboration.” — Scrum Guide 2017

I try and make the backlog no more than a couple of weeks in length. Anything else beyond that doesn’t belong in the backlog. The type of project may govern my ability to be able to plan further forward and in more detail, but I’ll not always dump all that into the primary backlog. I’ll feed them in over time. Visually a long, large backlog often puts teams off. It encourages impotency.

I try and make it coherent. So yes, all INVESTable and DEEP, but also clear. Each PBI needs to be clear to all and have understandability when you come back to it in a day or two.

I make the backlog reflect reality. Tasks are not scary the team therefore doesn’t avoid it and we don’t increase cycle time as the processing of the backlog becomes more complex as the size increases and tasks become aged. An engineer picking up a rotted PBI is no good at all. Hence the increased cycle time. I stay on top of the tasks, keeping them short, small and relevant. That’s my job. If we’re planning beyond a couple of weeks, I’ll pop those things into a higher-level plan.

In Summary

The backlog continues to be a nessacary component of the agile toolkit. You should absolutely use one. But like drinking good whisky, use it responsibly. Don’t let it become massively unloved and something your team fears. Don’t make it a political tool and don’t make it a PR job. Make tasks valuable and small, apply some restraint, follow all the good housekeeping and hygiene such as DEEP and INVEST and your team could appreciate the backlog.

Citations & references

• All about Lean – Mariosblog.co.uk
• Why backlogs are useless – Lucas F Costa