A Productivity Comparison of Kanban and Scrum

Scrum.  With Scrum, the story size ranged from 1 point to 13 points with a mean of 5.25, while kanban’s mean story size was smaller at 3.4 and varied between 1 and 8 points. The business team, while using Scrum, was too distracted with learning the product to be able to flesh out quality stories that could be collected into two weeks’ worth of work. With kanban, stories were fleshed out and prioritized just in time.  The product owner was on his toes because he knew the story would be picked and worked immediately in the kanban world.  With Scrum, our product owner assumed that a story may not be played until toward the end of a two-week sprint and by that time, the thinking went, the story could be fleshed out.  This is usually the case with agile but in our instance, it was extreme—stories were very vague before the sprint began.  Our product owner didn’t always have the appropriate motivation to create high-quality stories before being batched into a two-week sprint, but with kanban, the story was immediately addressed and, hence, had to be higher quality.

Why Did Kanban Work
Kanban worked in our case because we had better focus.  We were able to keep many of the stories as small, discrete pieces of work—no one story choked the backlog and stories didn’t need to be completed in groups. The business had the flexibility to change the backlog of any story not on the kanban board, which meant the process allowed the business to keep up with the development team.  The business focused on fewer stories, meaning that the stories they did focus on were of much higher quality. There were only two critical stories in the product backlog at any one time (limited by WIP), which enabled a fluid prioritization of the rest of backlog. The business team, was able to focus only the top few of the MWL, leading to better time management and clearer stories, which they determined the content of.

Along with the effect on the business, kanban has a number of other advantages that worked in our favor:

• Making Scrum lean was key for us. The development team didn’t spend any time in the planning meeting discussing stories that were never pulled into the workflow.  Only the next story on the kanban board was analyzed.
• Stories were higher quality. The business team only focused on the very top stories—the high visibility made it painfully obvious if this were not the case. Better stories lead to better development because of the clear business value.
• Stories prioritized to the top of the product backlog could be worked in a relatively short time i.e., as soon as a group of developers freed up. The temptation to “stop the press” and start on a critical story was much less when the expectation was that a story could be worked on within a few days.
• Our demos were at the story level and held immediately when a story was completed, leading to a much more focused demo with a smaller audience and less preparation time.  Team members were not distracted with the end of the sprint push or focus on demo as they were in Scrum.  Fortunately, the business team was engaged and those who had a stake in the stories attended the demos.
• The developers had small stories that they could complete quickly, leading to a good sense of accomplishment and a chance to react quickly to lessons learned from a story.  The small stories were a direct result of the business’s having enough time to analyze