Bye bye velocity. Hello throughput

The author shares his view of how Kanban within Scrum has affected his understanding of using throughput instead of velocity inside of Scrum.

The Professional Scrum with Kanban (PSK) course has now been out for more than 6 months at Scrum.org. As one of the first few trainers who wanted to teach this course when it came out, I find that it is a great way to combine the Scrum framework with Kanban as a strategy to deliver value to your customers.

Out of the many topics that we talk about in this class, I’ve found the use of throughput instead of velocity/capacity to be a positive change. I’ve taught the regular Professional Scrum Master (PSM) course for about 6 years now and when I get to the Sprint Planning slides, we usually extend the conversation around velocity and capacity. I pull up my complementary slide deck around relative estimation, poker planning, and charts to track velocity and we spend an additional hour on this topic. I answer questions about the meaning of story points, and how they should be understood, tracked, and used in multi-team Agile projects.

In the PSK class, this conversation is completely different. When I get to the Sprint Planning slides, I point out that the throughput history is used as an input to the Sprint Planning. With a few examples, I show how easy it can be to get from your electronic Agile tracking system (Ex: Jira) or on your physical Kanban board.

I then get a new set of questions from students which I find a lot more interesting. The conversation goes quickly around the variation in the size of the Product Backlog Items (PBIs) that are taken by the team at Sprint Planning. There are very few questions about understanding throughput. Students find it is a metric that makes sense to the business compared to story points.

While our industry has talked about poker planning and story points since almost the beginning of agility in 2001, I think it is more than time that the conversation at Sprint Planning shifts to historical throughput instead of using velocity. Maybe one day in the software engineering museum, we can see a deck of poker planning cards next to a set of punch cards.

If you’re interested in learning more about Kanban in another context, visit KanbanGuide.org

Share

Ready to empower your work teams?

This is your chance to invite visitors to contact you. Tell them you’ll be happy to answer all their questions as soon as possible.
en_CAEnglish

Learn how we helped 100 top brands gain success