A Productivity Comparison of Kanban and Scrum

Charles Suscheck has compared the productivity levels of a Scrum and Kanban approach to process management via an experiment that he and his team had undertaken. Find out what were their conclusions.

Initial problem with Scrum

Charles' team had been doing Scrum, but there was no balance between what the development and product business management were doing. The Sprints' backlogs were not definite, changes were being made even while the work had been in process, and the stories were often ill-prepared and unclear - this was simply unsustainable. Agile means change, but this was constant alteration, not iterative improvements. The underlying cause of this problem was the novelty of the product that the team was developing – no one really knew what to do, what to change or what to keep, therefore it had been impossible to manage.

Kanban as a solution

They first tried cutting the Sprints short – a one week Sprint had proven to long. The aim now was to keep it as short as developing one key feature, and to minimize the time spent in planning, estimation and demo. Since this didn't make much sense, they've decided on trying Kanban: no time-boxes, each of their “sprints” had become a user story, and assigned 2 people to each task. They had utilized the pull method, also applied a WIP limit to the system. Additionally, they developed a 10 most wanted list, which had been actively monitored and updated, including the input of the stakeholders.

The process

Once the features had been analyzed, they were placed in the pre-ready state (outside the board), and once there had been enough room on the board, they were placed in the Ready column. The next stages were of course In Process and Done. The In Process was split down to Started – Code/Test – Awaiting Test – Pending Release. The team was holding daily meetings, deciding their each daily commitments.

The transition

Thanks to the team's experience with Scrum, the change to Kanban had gone quite smoothly. They were initially holding retrospective meetings every other week, but this didn't bring much good, therefore it had been altered to holding a review as soon as a story had been completed. Although not ideal either, as the conclusions were rather near-sighted, they've stuck with this for then.

The results

Even though this was not a controlled experiment, the team was able to note a significant productivity increase. How they measured this is by comparing Scrum and Kanban story points per week. The results were astonishing, the outcome of the Scrum team's work were 1.26 story points / week and the Kanban team had achieved 4.26 points / week. Even to them this seemed too good to be true. Charles has a couple of things which could have added to this success to mention.

Other factors

The experiment had been conducted on one group of people, however the Kanban team had one person more than Scrum. When Scrum was introduced, the team had to learn the new Agile approach from the start, and it did take some time. When the switch to Kanban had come, it was more of an evolutionary change, much easier to adopt than a completely new methodology. Also, the story points were being assigned to tasks basing on their similarity to previously completed ones. Again – when the team was just starting to do Scrum, they needed to build the set of tasks with assigned story points to have something to compare to, and once Kanban came, this set was already quite well established. The task sizes had also differed between Scrum experiment (1-13 points) and the Kanban experience (1-8 points).

How come Kanban proved such a success?

Apart from the suitability of Kanban methodology to this team's process, probably the one key factor that made it work was the increase in the whole team's focus. There were fewer stories to focus on, therefore the ones that the team was processing were treated with more diligence, resulting with higher quality.

The key factors that determined the success of Kanban implementation:

• No waste in the form of time spent in planning meetings
• Higher quality stories and of a smaller size
• Easier prioritization processes than in set Scrum Sprints
• Story review right after the work got done - much more effective
• No time wasted at the end of the Sprint – since new stories are immediately available
• Fewer people were required to attend meetings - both review and planning – only the people directly associated with the story needed to be present
• The team had previous Agile experience

Clearly, Kanban has proven successful with Charles' team, resulting in a 300% increase in productivity. Although, they've lost the sense of rhythm and gradual accomplishment, that time-boxed iterations provide. There was also the fear of losing the collaboration opportunities, strongly enhanced by Scrum's team planning, in Kanban reduced to the parties involved only. Charles is happy to recommend Kanban to any Agile-experienced team, working with loosely coupled stories. He doesn't think Kanban is a solution to all problems, but it can certainly help many a team.

Read our article on Kanban vs Scrum »