What is throughput in Kanban and how do you measure it?

Apr04

What is throughput?

The number of items that the Kanban system members deliver to the end of the workflow, to the finish point of the workflow every time period.

Example: If your time period is in a day, you’d have a throughput per day. If it’s a week, throughput per week, throughput per spring, throughput per month, per quarter, per semester, and so on.

What is throughput based on?

Throughput is based on the number of work items and work items are valuable.

They value in terms of either:

customer value;

end user value;

market value;

organizational value;

the reduction of risk value;

societal value; AND

learning.

Each work item gives value.

When we deliver a work item and we hope we get value, it is potential value. We don’t really know that we have value until we get feedback.

How should you measure throughput?

When you’re measuring a throughput, you should be measuring the delivery rate of work items to the finish point on your definition of workflow in a given time period.

You can have a number of different finished points on your workflow. You’re allowed to have more than one starting point, more than one finish point. You just need a minimum of one.

So you could have for example:

throughput to done;

throughput to released;

throughput to got feedback from the customer;

throughput got to, got feedback from the customer, did a tweak and re-released…

and you get the idea.

You could have a number of finished points.

Don’t pollute your throughput number

What I see often is people get a bit confused and they compare apples with oranges and so what they do is they have throughput including sub-tasks under work items and work items themselves, which creates noise. This essentially pollutes the throughput number.

Make sure you’re comparing apples with apples. Make sure that when you’re counting throughput, counting the number of valuable work items that get delivered, they are valuable work items.

Different types of work items and throughput

There is another level of apples and oranges, which is the number of different types of work item that get delivered. Work item types are optional in the Kanban Guide.

They’re very useful in non-software, non-tech, where the difference in the type of work makes a big difference in terms of how long something actually takes.

So you can look at throughput in a time period for type of work A versus type of work B, but remember there’s going to be noise in the system there.

I prefer to measure throughput in a quarter semester, something like that. Even a quarter might be a bit too noisy.

What do I mean by noise? The basket of work might not be equivalent to previous time periods that you’re comparing against. Well, will they ever be comparable?

I guess if the work is in the complex space where you’ve got unknown unknowns, it’s not comparable at all.

Are you delivering real value?

So take it with a pinch of salt. Throughput isn’t the be all and end all. It’s nice to deliver outputs, and that’s essentially what work items are.

The quicker we deliver those outputs, the quicker we can find out and learn if we’re delivering real value.

And so the key is to look at value as well. Is there a way to measure value? There’s a danger that if you focus exclusively on throughput, you could be making the same mistake that some of the people who implement Scrum badly make, which is where they count story points to done and it just becomes a velocity game.

Some would argue that throughput is another way of getting into velocity. So, I’m not going to get into that argument here, but it’s a view that some people have.