Kanban vs Scrum. What’s the difference anyway?

Kanban vs Scrum. Which One Is Right for You? While both are popular methodologies for agile software development there is sometimes confusion over the differences between them and which one should be used when. In this blog, I will try and sort out the confusion so you can make an informed decision about which methodology is right for you.

A Short History of Kanban and Scrum

Like just about all agile concepts, both methodologies came from the manufacturing industry. Kanban was first developed by Toyota in the 1950s to optimize their production process. The methodology using a physical card, called a Kanban, as a visual signal to trigger the replenishment of stock by the previous stage in a production process.  

In 2007 an expanded body of knowledge about Kanban was created. This rapidly led to the concepts being adopted in a wide range of sectors and disciplines, including software development.

The ideas behind Scrum were first described in 1986 as a new technique for developing products, aimed at “bringing about innovation continuously, incrementally, and spirally” using a cross-functional team working towards a shared goal. By the late 1990s the ideas of Scrum were being applied to software development, since then it has become a standard software development approach for many organizations.

A Brief Summary of the Scrum Software Development Methodology

In Scrum, the work is broken down into small developments that can be completed in short fixed length development cycles, known as ‘sprints’.  Each team has 3 to 9 multi-skilled staff, who do all design, coding and testing themselves.

At the start of the sprint, the whole team meets to plan what will be done during the sprint. Every day the team holds a 15-minute ‘stand-up’ meeting or ‘scrum’ with everyone present, to track progress and update the plan.  

At the end of each sprint, the whole team reviews what has been completed (‘done’) and releases it for deployment. Anything that isn’t completed (‘done’) goes back into the product backlog, the progress board is wiped clean, and the process starts all over again. Hence Scrum incrementally releases functionality and fixes to users in a regular ‘heartbeat’.  

The principles of Scrum can be summarised like this:

• Organize your staff into small, multi-skilled, self-organizing teams
• Capture the requirements as ‘user stories’ which say what is wanted and why, but not how they will be delivered
• Break the requirements down into a list (‘product backlog’) of small, well-defined developments
• Sort the list by priority and estimate the effort to complete each item
• Divide the calendar into short fixed-length sprints of 1 to 4-week duration
• At the start of each sprint, select items from the product backlog that can be completed in one single sprint, expanding tasks as required
• Hold a daily meeting to review progress and assign ownership to issues
• Resist adding anything new into a sprint once it has started
• Maintain a ‘burndown chart’ showing work left to do versus time
• At the end of each sprint review what has been completed (‘done’)
• Then hold a sprint retrospective to review how the sprint went and agree on any continuous improvement actions

A Brief Summary of the Kanban Software Development Methodology

With Kanban, the development of each item from the backlog is started as soon as someone is available to work on it, and deployed as soon as it’s done. The principles of Kanban are:

• Visualize the workflow using a Kanban board
  • Split the work into small pieces
  • Write each work item on a card and put onto the Kanban board
  • Use named columns on the Kanban board to illustrate where each item is in the workflow
• Limit ‘Work in Progress’ (WIP)
  • Limit how many items can be worked on at any one time for each column
• Measure the average time taken to complete one item (‘Lead time’ or ‘cycle time’)
• Optimize the process to make the lead time as small and predictable as possible

In Kanban, there is no concept of a fixed time development cycle.  You can still have a release ‘heartbeat’ if that suits your needs, but you don’t have to.  Just like Scrum, large pieces of work are broken down into smaller components with incremental delivery of functionality. Each individual development is kept small enough so that it can be delivered quickly, ideally in hours or days rather than weeks.  

Kanban also uses multi-skilled developers, but you can have specialists e.g. testers. Often just one person is assigned to each item, but more than one can be assigned. When someone finishes an item, they select the next one from the board and start working on it.

There are usually ‘stand-up’ team discussions around the board to help allocate work, but Kanban doesn’t insist on this. The graphic above shows a typical Kanban board, with columns for the different workflow stages. The numbers above each column are the WIP limits, for example, the maximum number of items that can be in test at the same time is 3.

Kanban vs Scrum – in a Nutshell

Put very simply, Scrum tells you to have timeboxed iterations and cross-functional teams, whereas Kanban tells you to use visible boards and limit work in progress. Scrum delivers functionality at regular pre-set 2-4-week intervals, whereas Kanban delivers functionality at frequent, irregular intervals.

Kanban vs Scrum – Similarities and Differences

Both Kanban and Scrum are methodologies that provide good advice about workflows and processes for software development. Both are ‘agile’, much less prescriptive than traditional software development approaches like SSADM and Waterfall. Both use a ‘pull’ approach to decide what work should be done, break work down into smaller items, and use self-organizing teams.

You can choose to slavishly follow the Scrum or Kanban guidelines, ignore them completely, or adapt them to suit your situation (I suggest the latter).

Neither Kanban nor Scrum tells you everything you need to know to be efficient and effective in software development. Nor are they perfect, or a ‘magic bullet’ with guaranteed success. Both need an awareness of how they operate and knowledge of what you are trying to do with them, you can’t just download and install them.  Both rely on users describing what they would like in ‘user stories’.

This graphic shows how user stories on similar topics are grouped into Epics and Themes, then broken down into Tasks which can then be worked on.

There are, however, some key philosophical differences between these two important methodologies: To start with, Scrum is much more prescriptive than Kanban, as it has many more ‘rules’ over what you should do. Kanban leaves all of the detail about how you do things up to you, as long as you’re visualizing your workflow and limiting WIP then you are doing Kanban.

Scrum advises you to have three particular roles: A Scrum Master who protects the team from outside interference, removes blockers, and provides process leadership; A Product Owner who represents the products stakeholders, sets the vision for the product, gathers requirements (‘user stories’ into the product backlog and prioritizes the work; And the Team that delivers potentially shippable product increments from every sprint.

Kanban doesn’t mention any roles at all, it leaves it entirely up to you.  In reality, though many organizations still have roles that do pretty much the same thing as the Scrum Master and Product owner, even if they don’t call them that.

In Scrum, you must have a product backlog, a sprint backlog, burndown charts, and a product increment. You must also be doing sprints, sprint planning, daily scrums, sprint reviews, and sprint retrospectives.

Kanban doesn’t say you need any of these. That doesn’t mean to say that you can’t re-use some of these artifacts and activities from Scrum in Kanban. Most people do because approaches like daily team reviews are good ideas, but the Kanban methodology doesn’t say that you have to.

Scrum – What the Workflow Through a Sprint Looks Like

Here is a simple example of what a Scrum board will look like at different stages in the sprint. The board should be read from left to right.

This is the first day of the sprint. Four items have been planned to be delivered in this 2-week sprint.

At the end of the first week, two items haven’t had work started on them yet, one item is under development, and another has been completed but hasn’t been released for deployment.

At the end of the two-week sprint three items are done so they can be released for deployment. However, one is still being worked at the end of the sprint. It will be put back into the product backlog.

At the end of the sprint, the Scrum board is cleared, ready to be populated after the planning meeting for the next sprint.

Kanban – What a Workflow Looks Like

Here is a simple example of what a Kanban board would look like as items move through the workflow. The board should be read from left to right:

On the first day, there are four items pending, one in development, (the 3 signifies the WIP limit for this stage), two in final test, and two already done and released.

By the end of the second day, one of the items that were in development is now in final test.

By the end of the third day, the two items that were in final test on Day 2 have now completed and released. One of the items that was in development has moved into final test. Two items have been moved from pending into development. The WIP limit if 3 for development has now been reached, so nothing else can be started until one of these moves to testing.  New items have been moved into the pending state. The Kanban board will never be cleared. Items will be moved out of the ‘Done’ column once they’ve been accepted by the users.

Advantages of Using Kanban over Scrum for Software Development

Kanban can deliver individual items of new functionality much faster than Scrum, as there is no need to wait until the end of a fixed time period for release. This gives much better support for today’s fast-moving digital enterprises.  Kanban is also the better option for delivering urgent fixes, as with Scrum you’re not allowed to add anything into a sprint once you’ve started work on it. Development cycle times in single minutes can be achieved with Kanban.

Kanban eases the burden of estimating how much time each development will take to do and planning it into a sprint. It’s still good to have an idea of the effort for each item, but there is no need to get just enough work to fill a sprint. In Kanban, each item can take as long as it takes.  

Using a Kanban board enforces work in progress limits, so stops developers taking on more work than they can actually deliver. If your WIP limit in each workflow stage matches the number of resources available for that stage, then it forces people to work on one item at once. Nothing can be started unless there is the capacity to work on it. Lean and Agile thinking has shown that this is always the most efficient delivery approach.

What Are the Advantages of Using Scrum over Kanban?

Scrum encourages more team working than Kanban. Scrum is also easier to operate than Kanban if you have a mix of skills, experience, and capabilities in your team. In pure Kanban, every team member should understand the product and be happy engaging with the stakeholders, whereas in Scrum the Product Owner leads on this.  

If you’re not already using agile development methods, then Scrum can be an easier place to start than Kanban. It will get your team used to working together on short iterations, with daily team meetings, and a structured approach. Starting with Kanban could lead to your staff feeling pressured and isolated.

Scrum results in regular releases. Some users prefer this to the ‘drip by drip’ releases associated with Kanban. Having certainty around timeframes makes some developers feel more secure.

Having regular releases will also help the alignment with your traditional ITSM change and release management processes, such as weekly change advisory boards.

Can Kanban Co-Exist with Scrum?

Using both Kanban and Scrum at the same time within the same development team is unlikely to succeed, as it will lead to confusion and overlaps. You can use Kanban boards to visualize the sprints, but that’s not really using the Kanban software development approach. If you want to change from Scrum to Kanban then the best way is to introduce it one team at a time.

Kanban vs Scrum – an Item by Item Comparison

This table compares the features of Kanban with those of Scrum.

Related Posts

ITIL or COBIT or something else? Which should organizations choose?

How to Use Kanban to Become Insanely Productive: A Short Guide