*In this article references to “workitems” shall be construed as “product backlog items”.
What is throughput?
The number of product backlog 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 product backlog items and product backlog 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 product backlog item gives value.
When we deliver a product backlog 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 product backlog 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 product backlog items and product backlog 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 product backlog items that get delivered, they are valuable product backlog items.
Different types of work items and throughput
There is another level of apples and oranges, which is the number of different types of product backlog item that get delivered. Product backlog 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 product backlog 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.
Concluding remarks
Be careful with counting, because if you’re counting outputs, you’re not really comparing value.
Try to find a way to ascertain whether we’re making a difference to our customers. That’s probably the most important thing.
Even better if you can try to deliver maybe less outputs, to deliver more outcomes then you’re really winning.
Thank you.