A Productivity Comparison of Kanban and Scrum


Charles Suscheck compares the levels of productivity of Scrum and Kanban through a hands-on experiment that he and his team personally participated in. Learn the upsides and warnings about each practice to help you decide what might work best for you and your team on your next project.

Scrum is a great agile management framework for iteratively developing complex software systems, and it works well in many circumstances.  Certain problems can arise, however, such as a highly fluid product backlog, which make kanban’s emphasis on backlog flexibility a more attractive alternative.  Software experts like David Anderson, Corey Ladas, Dean Leffingwell, and Linda Cook point to small, loosely coupled user stories with an experienced agile team as key factors for productivity gains using kanban.  Yet, few studies exist to show concrete metrics in productivity gain.  In this article, I explain our application of reasoning for using kanban and then show how I computed that our productivity gains were more than 300 percent once we started using kanban.  I conclude this article with thoughts on applying kanban in your circumstance.

The Problem
We were in trouble. Our project’s business side began to have difficulty keeping up with the Scrum team’s productivity, and stories were neither groomed nor well thought out enough to be effectively used as part of the sprint. The product owner was changing the backlog at the last minute, inserting stories into the top of our product backlog on the day of planning, reorganizing the groomed stories out of the backlog, and even cancelling stories that were in the process of being worked as part of the sprint. The Scrum team was often faced with the unenviable task of cobbling together a sprint full of unknowns.

To make matters worse, we were ending the phase of large scale stories and entering a phase where alpha clients would introduce small, discrete stories in the form of bugs. A stream of potentially high priority bugs was about to hit us  requiring faster reaction than we could handle by collecting the bugs into two week iterations.  We had to find a way to make our process more lean.

While agile encourages change, the process cannot be chaos.  Scrum requires thought out stories with enough detail that allows for a coherent conversation with the product owner.  In our case, the product owner represented the wishes of a number of diverse stakeholders and a constant stream of bug fixes. The product was a new acquisition and everyone, including the product owner, was learning what it should do as we rebranded and integrated the product into the company line.

The Solution
First of all, the problem was really a symptom of an underlying cause that was not going to be fixed any time soon. The product was new and there were no product experts – we were all learning.  The product owner, stakeholders, and development team all were unfamiliar with the product, and we had no great vision to follow.  Abandoning a sprint, rejecting stories, or chastising the product owner was not going to move the project along.

We looked to apply lean principles to Scrum’s meta processes and considered ways to shorten the sprint length, the estimation sessions, sprint planning, and sprint demo length even further. This was done with the goal of keeping people working on stories that were of the highest value and well thought out enough that the utility of the stories could be explained. We found that one-week sprints promised to be too long.

After much brainstorming, we decided to use kanban as described by Corey Ladas. We broke sprints down from two-week timeboxes into a single story flow—conceptually a “sprint” became one story and we abandoned the timebox. We limited the teams working on each story to two people—which meant multiple teams were pulling from the backlog—and then kept the work in process (WIP) limited and used the pull technique. Additionally, we developed a ten most wanted list (MWL) for our stories before placing them on a kanban board, and held meetings several times a week to groom the list.


User Comments

Tim Thompson's picture

I maybe similar experiences. Rather than time boxing to a 3 week sprint laden with the excessive overhead that SCRUM comes with (aren't we Agilistas not supposed to aim for less process??) we opted for a quarterly release cycle and aim to deliver what the business asks for following a very loose Kanban approach. Our goal is now on delivering features for a release, not discussing at length how to break up a story into small pieces. It also makes for much more impressive demos compared to showing that in sprint 145 we added this button that currently does not do anything because that story is pegged for the next sprint.

The best of all, we cut down standups to two times a week, be ditched the retrospective, we no longer need to groom the backlog because it is fine if a task takes six weeks to complete, and we could replace the Scrum Master position with a junior developer who actually generates value for the business rather than put spiffy slides together and schedule meetings.

As soon as we ditched the flawed idea of 'Scrum' and the three week sprints our verlocity went way up, we evened out everyone's workload, and if we spend time in meetings it is about design decisions, not about 'how we feel'. If there is a need to discuss anything related to process we do it as needed.

March 7, 2015 - 2:48pm
Keith Collyer's picture

Very interesting article, thanks. One suggestion related to your comment about collaborative design not being emphasized. There is no reason why one of your "stories" could not be about design (or even, whisper the dreaded word "architecture"). Just because the agile world thinks stories are the only thing that is meaningful, the real world knows that that is not true. Better sometimes to do a restricted form of BDUF than have to refactor unnecessarily.

March 13, 2015 - 11:24am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.