James King

It’s actually been a long time since I have used a physical story wall or a physical story map that the team keeps referring back to.

These days I work with people across multiple locations and we all spend some of our days working from home. So I guess a physical wall with cards on it would be impractical.

I still use paper and pen for my own todo list though, and while I sometimes ponder moving to an ipad, Remarkable, or even phone, I never do.

One reason is that I like to change the format of my list from time to time. I usually have weekly goals and daily actions/meetings and sometimes I have a daily reflection, journal or idea. Sometimes I even have a “not to do list” and a list of annoying habits I want to change during the day.

So, while I could do all of that with a gadget, the paper version works better for me.

One key reason is that with paper, I am forced to recreate my todo list/plan on a regular basis because I have a fresh pager per day and because my notebook fills up and gets replaced. Thus I am forced to decide if my list still works for me each week and even each day. I also find that if I have to rewrite items on my todo list, I will either admit I will never get to them, or get them done to avoid rewriting them.

I also use paper because I am always “Co-located with myself”. I add comments and observations to my list in real time and then reflect on them at the end of the day.

I used to make a mess of the physical story wall in the same way, adding, changing, commenting and so forth. I fear sometimes that when we don’t have to clear and refill our story wall each week, we might keep old columns, habits and configurations that no longer work for us.

That feels like a loss, but even in spite of this I have come to love electronic story walls.

Online walls work really well

The main function of the “wall” is to make things transparent for their team, and maybe any stakeholders who become nosy or engaged.

Electronic walls certainly work well for this purpose and we can still tweak them, add comments, add new information, simplify things if we want to, its just that we don’t for some reason.

Another benefit of online walls is that, with care, you can get good metrics to highlight things the team might not notice, beyond what is visible on the wall right now.

I say “with care” because making metrics easier to collect does not generally lead to better metrics, but that is another topic for another day.

Best of all, electronic views of the work also work extremely well for cross team work, dependencies and scaling the view from a specific sprint/team/day up to a bigger portfolio view.

Some teams waste this opportunity by simply jumping between “walls” or views that were designed for a team of 5 people, without thinking about how they can use different views to zoom in, zoom our or look from different perspectives.

On the other hand, teams who think about how the wall will actually support the discussions and collaboration they want to achieve, can hone multiple walls to really support them, with fairly little effort.

With backlogs, I am not so sure

What I realised though, is that the backlogs don’t get better when they are online. They should, but they just don’t seem to.

In the old days we had limited wall space, so we would create a story map, add some models, run out of space and then throw things away. This shocked people sometimes because of all the knowledge that was “lost”, but in fact I think the knowledge was already decaying the longer something stayed up on the wall.

Adding things to the wall created some duplication of information and a real limit to how much information you could add in one place, but it also forced people to map things with some context and to consolidate information into epics, models and even allegedly easy to find documentation that was available for anyone with an interest in finding it and an advanced capability in archeology.

I read a whole book on replacing this adequate but not ideal approach with an easier way to go from ideas to “stuff we should do” and then break it down into small pieces of work that we are actually doing today. Following the guidelines in the book meant that the old backlog (electronic or not) was replaced with deliberate management of ideas, the way backlogs were meant to work when small teams of 5 people sat together in a crowded workspace with pinup boards and whiteboards next to them and old cups of tea sitting on their desks half drunk.

Er – the tea was half drunk, not the workers, who were engaged, working hard and totally not needing any managers to track or micromanage them.

You can learn more about the book here, if you are interested https://www.google.com.au/books/edition/The_Rock_Crusher/iMPWzwEACAAJ?hl=en

What has this got to do with backlogs being online?

The Rock Crusher approach assumes that we are going to spend time designing our work and collaborating on continually refining what we need to do next to create value.

The backlog allows us to simply put things in it for later. I think this is what makes the backlog so ubiquitous among modern teams. They are easy to create and take little thought to maintain:

• It does not require the whole team to see what is in it;
• It does not require a lot of thinking to define it, nor reflection on how to optimise it on an ongoing basis; and
• It does not expire and need to be recreated the way my todo list and cards on a wall do.

But this ease of use is at the expense of value. The ease of dropping things in the backlog means that we do not need to “Crush Rocks” or work out how to story map. This then becomes an issue because the backlog is a bunch of things that are not structured in a way that will help us prioritise, optimise or gain throughput.

The rock crusher is one approach to fixing this, but there is another one. Modern product teams have data that they assess for insights, actual testimonials and other views from customers and other useful information. This is actually a backlog, but it may not actually be linked in a cohesive way to the backlog of work to do that a team has.

So now we have two backlogs.

In between though, architects build technical roadmaps, customer support teams have ticket backlogs and good product people create clear roadmaps that take the insights, the technical roadmaps and the support team problems and turn them into a useful way forward.

This roadmap them becomes the source of truth, which makes it seem more important than the “team backlog” to me.

The team breaks things down to work on them though

Roadmap items are clear, but the way they can be sliced into value is not.

So the team take some roadmap items, hopefully do some discovery and then hand them to teams to turn into value.

In theory this aligns perfectly with the backlog the team has, both their product backlog and their sprint backlog. But the ease of use in pouring stories and epics into a backlog means that it gets ever fuller, unless it is constantly refined.

Scrum solves this for us in theory, by saying the PO will refine the backlog constantly, which they would, if they were not also testing, talking to people, hopefully seeing what customers are doing and so forth.

So the PO refines what the team needs to work on soon, but does not go back and tear up the rest of the todo list (backlog). Doing so would make sense but it is never urgent, so the smart team will always be focused on something more pressing.

Now I think I have finally come to the crux of the problem. But the unrefined clutter is not the problem, it is the symptom.

My todo list serves me well. It is a tool for time management and a way to reflect on things, plus something I doodle on. It relieves stress, helps me turn up on time, prepared for things and keeps me focused.

But the backlog may not be doing the same for us. So the crux of the problem is that we are tricking people into seeing the backlog as an end in itself, rather than something that we use to work better.

When we say “backlog”, a lot of people think we mean “Jira”, which it is not. Jira is a place to keep our backlog (or part of it) and it works well enough in that respect, just as a notebook works well to hold temporary information for me.

But if some things are in Jira, others are in a product tool and still others are in some other AI tool, we don’t actually know what the backlog is. And since the PO is meant to refine it, they will get stressed about not doing something, that would, if they did it diligently, not actually add any value anyway.

What can we do?

We could just throw the backlog out then, but we still need something, and once we create it then it will devolve into the same mess.

We can look at our entire insight to value process, and it is worth doing so, but it is a big boulder of an epic and hard to do when we are busy.

My todo list is personal and it works for me.

Maybe teams can similarly take a step back and ask what they need.

Starting with the story wall, they can ask what they need to reduce the cognitive load of the things not yet on their story wall. They might want story maps, product roadmaps and models to build from, so talk about what this will look like.

Then build the backlog that looks the same. Use epics if you like (I do) and keep some information in a product tool, since it is useful for what-if planning and communication. Then start rebuilding the backlog again so it works.

If the story wall visualises work in progress, then the backlog should visualise work nearly in progress. So don’t worry about creating the backlog as a goal- ask how a backlog could help you with that.

Throw out old backlogs or change your team name and create a fresh one. Bulk close or delete things, but don’t try to perfect the backlog, just keep seeing if it is useful to you.