Entropy and the backlog

"Lack of order or predictability; gradual decline into disorder." - Google

When we create something, either documents, products or software, entropy has an effect on it. At the conception of an idea entropy already starts. The specifications change when we get further into completing our creation. The world around us changes, new things get invented, old things die, a lot changes in the passing of time. Over longer periods of time cities crumble into decay, governments change and even the way we view the world changes. In short, live is about change and coping with change. A result of this continuous process is entropy.

When we develop software we use specifications, we already found out that a big design up front isn't working very well. We only get what we designed eon's ago and not what we need right now; the world has moved on. A new concept was born about twenty years ago: agile working. To understand how slowly time proceeds sometimes, most big companies just start to adapt this way of working; they see that smaller companies that are agile, lean and adapting fast. Those companies are a danger to their industry. Using an agile method can help plan short and adapt to market changes.

This concept spawned a number of working methods of which one of them was scrum. One part of scrum is working with backlog's. A backlog is an ordered list of items or stories as we mostly call them, which is maintained by somebody that is responsible for the product that is created and maintained. But here come's entropy, the backlog killer. When the backlog is not maintained, items on it begin to fall into decay. They slowly lose their priority and therefor any meaningful existence. This article is not about product ownership, but about backlog's and entropy.

So what happens to an unmaintained backlog? As from my experience, the backlog just keeps on growing. And eventually it will get big enough that nobody understands the purpose of all the stories that are told. Which also means, that nobody knows exactly what the product is that is supposed to get build. In nature old things die. In most applications that manage a backlog, items live forever. There is no dying mechanism, stories that were written down by a stakeholder (someone with a more than average interest in the product) become irrelevant or even not understandable any more. Team members spent too much time looking at the backlog trying to understand what the purpose and demands are for the product in the making. So, entropy happens to the contents of a story. The story dies but is never cleaned up.

I see two camps in backlog maintenance. On one side there is the camp that tries to save everything that is ever said about the product. The backlog might have grown to immense proportions and they have a day job maintaining the log. They find it important to know all the stories, their context and purpose. Perhaps they feel even important because they are the centre of attention when people ask about the product. They are the know-it-all's. I can understand that feeling important might seem important, but it isn't practical, nor is it fun. It would be far more practical if everybody who works on the product has a chance to understand the backlog, the importance of the stories and the context of the product.
On the other side there is a group of people that clean up their backlog, but keep items in parking lots, afraid to lose information. The parking lot becomes covered with dust and the items lose its purpose. Entropy at its best. People place these items in the parking lot because they spend time to create the stories and find it a waste that their time was for nothing. But was it? Is it a waste to throw away a story like that? Does this story deserve to get wrecked and covered by dust over time?

In my opinion a backlog should be clear and up to date. This means that we give stories a right to die. If there is information in stories that we shouldn't lose we must write down that information in a system with a documenting purpose (entropy applies here as well). Within a development team and with the product owner we must create rules about the death of a story. It should be bound to time, to contents, to relevance. When a story hasn't been picked up within the allotted time, when it is not ready to be picked up or when it loses its relevance, the story should be finished. Drag the story to done, won't fix and clear up the backlog. Even better, automate this process, just like nature does. Incorporate entropy as a fact of life, let outdated stories die off and don't waste time and effort on them anymore.