Modern PM

Why I take the view that putting tasks into an icebox is a dangerous business - in summer as during winter. And what can be done about it.

What is an icebox?

A couple of years ago I overheard some developers, I had the chance to work with at that time, talking about an icebox. It was summer and it was hot and I was like: “Yay, ice cream. Yummy!” The look they gave me made me feel like a little boy again. A stupid little boy. So let us talk about some theory first and then see how that correlates with reality. Now, what is an icebox? (Besides the one where you can find ice cream and cold drinks.)

When starting with Kanban or an agile methodology like Scrum, things are mostly and hopefully new and exciting. Requirements are cut into user stories and tasks. And those tasks are now starting to wander across that new and shiny whiteboard. From the To Do column / row / pipeline / step / whatever-fancy-name-your-scrum-coach-gave-it, to Work in Progress and finally to Done. After a while, most teams figure out, that some sort of testing state makes sense. Fewer teams then realize that the journey of a task won't stop after it is done and add a column named Released. So good, so far.

Die hard

Sorry for starting with movie references. Again. I promise this was the last for this article. So we have our Kanban board and our tasks. And everything runs great. But then old habits begin to sneak into our new agile world. Customer value sometimes tends to come in disguise. Priorities are not always that easy to decide. And so requirements start to add up. And at some point, somebody had the <zynism>great</zynism> idea to add a place on that whiteboard where all those tasks could find a new temporary home: the icebox.

So, a long story short: an icebox is a list of requests and issues that nobody is going to work on. Low priority tasks, minor bugs. Things, that are requested every now and then but that represent a low value. So, in theory, it is a kind of a parking space for tasks.

There is always that reality

And in theory, this sounds like a good idea. But here comes reality kicking in theory's door. Because let us be honest: in real life that home is not temporary but forever. It is not a parking space, it is a cemetery. Task Sematary. (Remember, when I promised to stop with movie references? Well... sorry!) Those tasks never ever get done. Why? In my experience there are two reasons for that:

1. Their priority is too low. This is one of my issues with agility. Standstill through a constant prioritization. When only the currently most important things are worked on - who will take care of the right things?
2. Because the world around that requirement is changing. Fast. And back then, when somebody wrote it down, it surely had its reason to exist, its customer value, its raison d'être. Now, after hanging on that whiteboard for some time, the basic conditions likely have changed. And with them, the necessity of that requirement has changed.

So after a while, we have requirements that don't represent that importance anymore they once had. And some years ago it was common for tasks to grow old. Think of all that councils and task groups and management layers such a requirement had to go through. Still has to go through in many companies. Those companies that actually don't feel the pressure to change that hard. And in that case, it is not exactly good, but also not bad to take some time. But in fast moving environments (and these days we see a lot of environments changing) it is deadly. So let me formulate it differently: after a while, we have requirements that don't represent that value anymore that they once had.

An icebox inside an icebox

I guess we all agree that we don't want to have these requirements around our board. But for me, there is a situation that is kind of the same: user stories or tasks inside a backlog. Well, not the same. Even worse. At least an icebox is a sign. Inside a product backlog, those "parked" tasks just add to obscurity. It reduces the maintainability and - more even worse - the transparency of that backlog. (Well, maybe sometimes that is intended. And if it is intended, then an icebox should not be our number one priority.) So we should scan a backlog we have to work with for exactly that user stories. And it does not matter if our role is project manager, or Scrum Master, or Product Owner, or whatever here. Because that user stories represent an icebox inside an icebox. And double pain usually is not a good thing.

How to handle these requirements

I guess it depends a lot on the environment and the team and the culture how such "parked" tasks are handled. A thing that I have made positive experiences with are mold points. Every morning you place a dot sticker on every requirement on your board that has not been pulled during that sprint. You can also mark them with a felt pen. As those points will grow (like mold), you will reach a point (pun intended) where you won't be able to figure out what this task originally was about. And in that very moment, you can remove it from the board.

If you are using a digital equivalent of a Kanban or Scrum board, those mold points obviously won't work. Here you need to make those scruffy tasks transparent. And I know, this is hard work. And it is not easy to be that annoying person who is crashing every daily meeting with "Any news on that requirement?". But in my eyes, it is worth the pain. Because a clean backlog or board will push the effectiveness of a team.

The best for last

So for me, there are two ways to deal with a requirement: either it generates enough (customer) value to have a high enough priority to be done: do it. Else: throw it away.

And here is the only good thing about such an icebox: the "parked" requirements have already been identified and clustered. So you can grab the whole thing and throw it away. Time for an ice cream.