Finding the right task size in kanban

Image © S J Pinkney

Imagine you were put in charge of building a pyramid for your customer, an Egyptian Pharaoh. You are in a hurry because you have heard bad things could happen if the Pharaoh dies when his gateway to heaven is still a construction site.

It would be nice to have a single large task that says "Build a pyramid", order it from outer space, and have the entire thing airdropped. Unfortunately, you do not have access to alien technology. You have to build the pyramid one stone at a time. In fact, "Put stones on top of each other" is still a very large task. If you do that, you are almost guaranteed to hit trouble down the road. Let's break our task down into smaller chunks first. Later we will see what might happen if you do not do that.

Smaller tasks offer several advantages.

"Build a pyramid" decomposed

Begin by breaking down your task into several rough subtasks. You will get something similar to the list below:

Choose the size of the stone blocks
Find nearby quarries to supply the stones
Build barges strong enough to carry the stones
Find a way to load the stones to barges
Find a way to lift stones to the top of the pyramid
Find enough ~~slave~~ voluntary labor to put the stones in place
Supply enough food to keep your labor force working

These tasks are still large, but they give you a much better idea of what you are up against. You should continue breaking each subtask down into more subtasks, but before that, let's take a look at what might happen if you do not do decomposition.

"Build a pyramid" as one large task

Large tasks are actually projects in disguise. With size comes several disadvantages:

You receive less feedback
After you have cut 5,000 tons of stone blocks and built 100 barges to carry them, you learn that the Pharaoh found the size of your stone blocks a bit on the small side. "Those puny stones are too small for a mighty pharaoh like me. Make them twice as big," he orders. If you had smaller tasks, you would have learnt that a lot sooner.
The success of a large task is determined by the least successful component
Can you really build a pyramid if you have not quite figured out how to lift five-ton stone blocks 300 feet high?
Work expands so as to fill the time available for its completion
Large tasks usually have due dates far in the future. The result? No sense of urgency and low motivation.
Tasks can get too big to fail
After you have spent half of your budget, you discover that you do not have enough workers to finish the task on time. Unfortunately, the only solution is an expensive war with a neighbor kingdom or two to ~~capture~~ find more workers. You cannot just cancel. So, your task drags on forever, consuming ever more resources.

What is the right task size for your team?

In kanban, there are additional advantages of using small tasks:

Work In Progress (WIP) limits work right. It does not make much sense to have a WIP limit of 3 tasks when each task has 5 hidden components each.
Visibility is better since there are no hidden subtasks.
You encounter fewer bottlenecks. Large tasks tend to block capacity more.
Your cycle time (the average time to complete a task) becomes stable since there is less variability in small tasks. In other words, fewer things can go wrong.

Make tasks as small as possible, but not smaller. Sometimes you can go overboard and make a task too small, but you can always increase its size later. The opposite, however, is not always possible.