The Difference Between Scrum and Kanban
By: Ben Staples
Tags: Technology, Product, Product Management, Tech, Agile

Originally published on www.Ben-Staples.com.

For people stepping into an agile organization or team for the first time, a lot will seem new and unfamiliar. People will throw buzzwords around like throughput, standup, and WIP. As you get more familiar you’ll need to start educating yourself on some fundamental decisions agile engineering teams face so you can craft an educated opinion.

Looking for background on what agile even is? Read more on the difference between agile and non agile methodologies.

I’ve worked as a Product Manager on agile teams using both Scrum and Kanban workflow methodologies. One of the big first questions that seems to come up frequently is:

What is the difference between Scrum and Kanban?

Scrum and Kanban are two agile methodologies that in the tech space, are used to organize software development teams to develop new software as fast and efficiently as possible.

They come from different backgrounds:

Scrum: Was developed into a formal process by Jeff Sutherland and Ken Schwaber in 1993 with the focus of improving how software teams deliver value.

To learn more about scrum, hear about it from the creator himself and check out this document: Jeff Sutherland

Kanban: The origin story of Kanban was a lot different than Scrum. Kanban came about back in the 1940s, and was first created to optimize Toyota’s physical manufacturing process for both quality, a reduction in waste, and getting more value (or cars) delivered to the customer.

Talk about crazy, Scrum, coming to life in the last few decades, compared to Kanban, used for building cars back in the day!

But the goals are the same; deliver the most value to the customer as efficiently as possible.

Let’s talk about the differences between Scrum and Kanban:

1. Ceremonies:

While ceremonies used can differ by team, for the most part they are generally the same. Both Scrum and Kanban based teams generally have standup (a gathering during the day to review what was done and what needs doing), should have retrospectives on a regular basis, and should have grooming sessions (where the Product Manager presents upcoming tickets and works with the team to break the tickets into tasks the engineering team can work on).

One difference is that a ceremony called planning doesn’t really happen in Kanban but is essential in Scrum. In Scrum, planning is necessary. Every sprint (or 1–2 week period), the team will sit in a room for an hour or more and think about what they want to get done within the next week or two weeks. By the end of planning, they have a list of tickets and features the team would like to get done during this time, and have laddered up those tickets or features to a sprint goal. A sprint goal, for example “This sprint is successful if XYZ happens” is generally phrased in a way that is customer oriented.

Kanban doesn’t have planning, but does prioritize things in a different way which I’ll get into now:

Photo by Elena Taranenko on Unsplash

2. Focus:

Scrum and Kanban drive significantly different views of what to focus on for the engineering team.

In Kanban: Tickets and new work are first prioritized in the backlog in a stack ranked order. As engineers finish off tasks that they were working on, they go to the top ticket in the backlog and pick that up. There is no discussion in terms of prioritization or lack of clarity in terms of what should be picked up because the answer is always clear; the first ticket on the top of the pile.

In Scrum: Work is planned in sprints. Through a planning session, the scrum team and Product Manager collaboratively align on how much work can be pulled into the next sprint, and the priority of that work. Scrum teams can work off of 1 week sprints, or 2 week long sprints depending on preference. Along with aligning on how much work can be pulled into a sprint, the scrum team and Product Manager must also align on a sprint goal. In an ideal world, each sprint should have a goal that includes getting working and finalized functionality live to the customer and adding value. Once the scrum team starts the sprint, they work through the tickets prioritized in planning, all with the focus of building towards the sprint goal decided.

3. Limits:

In its simplest form, Scrum and Kanban are both ways of driving focus for engineering teams.

Photo by Ludovic Charlet on Unsplash

They do this in different ways through artificial limits set on the team: Scrum: In scrum, the limit is time. Focus is constrained by sprints; 2 week blocks of time that include outlining what the team aims to do during that time at the beginning, and a retrospective capping off the sprint and thinking about what could be improved for the future. Generally teams running scrum will have no other self imposed limits.

Kanban: In Kanban, the focus is a count of the number of total features or things the team is working on at one time. Kanban is a continuous process; teams don’t plan out in weeks, but instead just continuously plan. What the team is inhibited by is WIP limits. WIP stands for Work In progress. A team sets a WIP limit as a way of limiting how much work a team can take on at one time.

As a super basic example, let’s say you run a factory building cars. Each car needs one steering wheel, and four tires. You have two employees, Sally Steering, and Tony Tire. Both of them can make one of their respective products an hour. After the first 8 hour day, Sally has made 8 steering wheels, and Tony has made 8 tires for the car. That means that by the end of the day, only 2 total cars could be shipped off to a customer because there just are not enough tires to make up for the surplus of steering wheels Sally is cranking out. This also means after a month, the factory will be full to the brim with steering wheels that are not needed because Tony just can’t make tires fast enough! Work has to be shut down while we clean out all of those excess steering wheels. HOW RIDICULOUS!

But instead let’s put a WIP limit. Sally will have a WIP limit of 1, and only make a steering wheel once there are 4 tires completed and ready to go. Well for the first 4 hours Sally gets to work each day, she can’t make a steering wheel because there are not enough tires ready to go, so she moves over to Tony’s station and helps him make a tire or two. With this slack in the system, the factory can almost double the amount of cars they produce and no one is drowning anymore in a sea of steering wheels.