One way of handling small tasks on a Kanban board

I often get the question how to handle small tasks on a Kanban board. Many teams I’ve talked to, especially maintenance and operations teams and teams not doing software development, have a hard time convincing themselves to actually write and track stickies for tasks that can be done in less than an hour, sometimes in minutes. Is it really worth the overhead? The tiny ones would go directly into “Done” anyway, so what’s the point?

The question can of course not be answered categorically. You have to ask yourself what the purpose of your Kanban board is, how the small tasks fit into that and a lot of other questions specific to your own context. However, here are a few of my reasons to consider tracking them in some way.

• Even if the tasks are small, if there is a lot of them the context switching and thrashing will affect your ability to do other work.
• What starts out as a small task can often turn into a bigger task because of unexpected complexity or other problems. “Oh, that’s just a five minutes fix!” Yeah, right…
• Even if the amount of work you are doing is small, you might have to wait for someone else’s input or the task can become blocked for other reasons.
• In my experience, a lot of these small tasks are failure demand, i.e., they are tasks created because we have failed to deliver the actual value in some way. If we can collect data on this and analyze it we might be able to get rid of the root cause of the failure demand and remove it, freeing up resources that instead can be focused on delivering value.

But does this really mean we should track every little task in the same way we track the normal work items? Probably not. Inspired by the excellent TV series “Homicide: Life on the Street”, where a big whiteboard is used to assign ids of unsolved murder cases in one color and then changing them to another color when solved (see my other blog post about this), I came up with an idea that has since proven useful for other teams too.

When a small task enters the workflow, we write down the tracking-id of the task on the board. Some teams have individual columns for team members, others just one for the entire team, whatever makes sense in the context. Once we have finished the task we strike it out on the board. Towards the end of the day we go through the column to see if there are ids that have not been crossed out. If we find one that isn’t finished, then apparently it wasn’t such a small task after all, so we write it on a sticky and put it in the regular workflow annotated with the information needed (blocked, waiting for info etc). And we draw a line under the numbers to indicate that this day is over and the next begins below the line.

After a week or so, we look at the small tasks log and analyze it. What patterns can we see? Is there perhaps a spike in demand Mondays and less towards the end of the week? How could we adjust our capacity based on that knowledge? Could we try to even out the arrival of the tasks? How much of it is failure demand? The same type of failure demand? Could we easily get rid of that demand by changing anything in our process? How many of the presumed small tasks actually turn out to be bigger than anticipated? Is the amount of small tasks so big that it should affect the WIP limit for the team or for individual team members? Maybe we could put a sticky in the usual workflow with an avatar of the team member currently in charge of the small tasks to indicate that she shouldn’t take on so much other work on the week of her being in charge? And put a sticky in the ToDo-list for the person that performs this duty the next week, so that he remembers to finish stuff and don’t take on a new big task towards the end of the week? And so on and so forth, whatever makes sense to the team.