Backlogs considered harmful

There are somethings we do under the pretense of being useful that are actually harmful. Unscheduled stories and bug reports in your ticket tracking system are an example.

Creating a ticket is easy when you are in the moment. However, once produced these artifacts have to be read and understood multiple times in the future. Each time you read a ticket it costs time. How many times have you given up trying to find some ticket that you think you wrote a long time ago and just entered a new one? How much time have you spent sifting through the same tickets every iteration deciding repeatedly that they are not important enough to actually schedule?

I am not saying that you should not enter tickets in your issue tracker. I am saying that doing so is not free. Therefore, you should consider very carefully whether the story or bug you are about to write will have a net positive value over the life of the project. Most likely it will not.

My rule of thumb is this: do not write it down unless you are willing to schedule it right now.

Willingness to schedule a bit of work is proxy for its importance. It is easy to pretend everything is top priority. If you are not willing to prioritize a bit of work before something you have already decided you want, it is obviously not very important.

If it is important you will not forget

I think the idea that you will forget something important is the scariest part of this approach. That fear is just silly. If you are passionate about an idea you will not forget it. If it is important to your customers they will not let you forget it.

Let me ask you a question: if neither you nor the customers care enough about an issue to get it on the schedule should you be expending effort on it?

To me the answer is clearly no. If you see a potential issue or have an idea let it rest until it becomes important. Odds are it never will become important and you will have saved a good deal of every one’s time. If it ever does become important the fact that six months ago you wrote a ticket vaguely related to an issue people are having now will not help anyway. You probably will not even be able to find that old ticket.

Corollary: todo comments considered extra harmful

Notice that my rule of thumb basically rules out todo comments altogether. Every todo comment is not only an unscheduled story, but an unscheduleable story. Even if the todo comment were a story in the ticketing system it would never, ever be scheduled. If it had a chance the developer would have written a story instead.

Todos are far worse than mere unshecheduled stories. Todo comments are a way for the developer to transfer some of the weight of the decisions that they made to future generations. A tax, in effect, on future generations of developers in order to assuage the author’s insecurities regarding decisions they have made in the code.

To the authors of todo comments i say, own your decisions. If you are not sure of what to do get a second pair of eyes now. Whatever you do, don’t burden future developers with your indecision. Right or wrong it will work out better if you make a reasonable decision and own it until there is some evidence that it was wrong.

Comments 2

  1. murray wrote:

    This is a bit of a straw man argument. Do not write it down unless you can schedule it gets you into a waterfall approach. If either the developer or the customer leaves the project all unwritten ideas, context, and learning leave with them. The human mind is fallible. It does not give you the exact information you require in the correct context every time. That is why people write lists. Many industries such as medical and aeronautics rely on checklists for this reason.

    Another approach would be for a team to delete all backlog stories every few months unless someone is willing to fight for them. If there is no passion to defend a story then no one believes in the value it will generate.

    Posted 27 Dec 2012 at 11:21 am
  2. Peter Williams wrote:

    Murray, i don’t consider it a straw man argument and i don’t think it leads to a waterfall approach. I prefer avoiding the cost of recording lots of ideas (requiring some effort) and then deleting most of them on a regular basis (requiring some effort). It is possible that in some situation willingness to schedule is not the optimal threshold for letting something into the backlog but some sort of gate is very useful. Just because you think some idea cool is not enough justification for wasting your colleagues time in perpetuity by recording it in the ticket system. If you really need to tell someone about an idea why not buy your colleagues a beer and expound its virtues. If after that it still seems important prove it by bumping something else. If it does not seem all that important at least you will have had a nice time with some friends.

    Don’t worry about the idea guy being hit by a bus, either. If the idea is so novel that it has, and will, never occur to anyone else it is probably too novel. Ideas are easy; time and motivation are the scarce resources focus of perserving them, not ideas.

    PS: i can see some arguments for recording bug reports even if you are not going to schedule them. I’d be interested in reading a good articulation of why always recording bug reports is a good idea.

    Posted 03 Jan 2013 at 3:27 pm