Bye Bye Velocity. Hello Throughput.

Nice post. Could you elaborate a little bit on your answer about PBI size and throughput?

As Product Owner, I just look at the amount of PBIs which moved from "Plan" to "Done", and take this number as a reference.

Gives me enough information to have a decent forecast. Everything else is overengineered.

Sounds similar to the no estimation approach where items are counted. This works fine if item sizes are close to each other (Shifting the burden of estimation to do work breakdown to same level of granularity too keep it accurate - either could work). Is there a body of knowledge to read more about the approach? I a strong advocate of throughput planning (SAFE) and Theory of Constraints / Lean Flow and I find velocity a great tool to do it. It is a fine balance between over investing in estimation and abstracting the variance of output too much to see the origin of pattern changes. In my experience when I track points claimed, shrinkage and unplanned effort I can quickly identify changes in team performance where without that it can be less emperical and more HIPO towards what root cause gets attributed to changes (Cohort analysis on the right level helps not only identifying changes but can attribute it to right cause).

Thank you for sharing your own experience Marius.

In regards to your question about a body of knowledge, if it is around throughput and Kanban, I strongly recommend Daniel Vacanti book Actionable Agile - Metrics for Predictability.

Great thanks, will look it up.

Actually, according to Little's law the first outcome of limiting wip is decreasing lead time or decreasing throughput, not the opposite as mentioned in the post.

How do you identify / measure throughput then? Are you using number of items that go from plan to done state in a sprint? How do you differentiate that from velocity?

Hello, congratulations for this article! Can you please inform whether is this scrum.org´s official understanding? (using throughput instead of story points) Thanks

I cannot speak for Scrum.org on this matter. In this blog post, I wanted to share my own experience where the use of throughput has changed my execution of the planning and refinement meetings. With the use of throughput as a metric to help the development team forecast work in a sprint, conversations about estimation not taking into account unplanned disruptions have been limited. I've found throughput to implicitly take into account unplanned work.

If we look at the Scrum guide, it doesn't mention velocity or story points. I'd be more than happy to see where Scrum.org has an official position on this Tom. Feel free to point me in the right direction on this matter.

Good question and I hope my answer can help you shed some light on this difference.

The Professional Scrum with Kanban course uses the Kanban Guide for Scrum teams as its reference point so I'll use this document to support my answer.

In this document, the definition of throughput on page 7 is:

The number of work items "finished" per unit of time. Note the measurement of throughput is the exact count of work items.

So an example of throughput could be 5 PBI/sprint.

As for velocity, it is measured in terms of Story Points per sprint or iteration.

So throughput is a number of items finished per unit of time while velocity is the number of story points finished per unit of time where a story point is an arbitrary value.

For a longer description of throughput, I highly recommend Daniel Vacanti book Actionable Agile - Metrics for predictability. Chapter 2, The Basics metrics of flow, and starting at page 31, explains in details throughput and the difference with story points/velocity.

Good catch Alexandre. I was incorrect in this sentence and while I took a good ten minutes to figure out what I wanted to express, I can't give you a valuable reason of why I wrote that. I've removed the sentence from the article to avoid misleading future readers.

Good to hear from you Louis. I appreciate your comments over here.

Surely you meant "increasing" throughput?

Nice topic and interesting discussion. When measuring throughput, how do you handle the variation in the size of the Product Backlog Items (PBIs)?

Wanted to understand what is missing for given scenario - If have a 1 story of 13 Story Point, throughput will come 1, but if same story is divide to 13 stories of 1 story point each, throughput will come as 13, thus it will show higher throughput achieved but in both case velocity will remain same, what to choose in this scenario

The argument that item sizes must be close to each other for throughput forecasts to work turns out to not be true. I've been fiddling with this methodology for a couple of years - on my own as my org uses traditional story pointing and team velocity. I've found that size or complexity of stories makes no difference. The slope of your throughput line will remain relatively constant. Over several months, I've found the differences between projected throughput and actual throughput to be statistically insignificant, even though the story points varied widely. What's important is not consistent story sizes, but a large enough historical model to reflect story point variations. Randomization will take care of the rest.

During this time, I've seen trends showing that 3 point stories take longer to complete than 5 and 8 points stories, and 1 point stories take longer to complete than 2 point stories. With that kind of input, it's hard to see how planning based on points and velocity can have any validity.

But my throughput projections remain constant and correct.

My approach is to define throughput as "how many items were closed today?" Closed as in, no more work needs to be done on this. Unfortunately that's a wiggly definition since my org still does end-of-release-regression-testing. So technically nothing is complete until the end of regression and the product is handed off to production. But closing all stories on the same day provides no useful metrics.

I also like estimating based on Throughput. But the challenge is this. Your team's Throughput could be 30 if the items were small and in the next Sprint, you could have a Throughput of 5 Items, if your items were bigger. So it is difficult to have a statistic on how much the team can deliver. What do you think?