Scrum vs Kanban: Which should you choose for your business team?

So, you’re looking to introduce agile working to your team. You may be a marketing, operations, HR, or finance team. To be honest, it doesn’t matter what you are because anybody can be agile. Thing is, there’s lots of ways to be agile, so which approach should you ascribe to?

The two most popular approaches are Scrum and Kanban and, to be honest, most teams choose one or the other. You can’t really choose wrong, because Scrum and Kanban are just two different rides to the same destination, that destination being: delivering value to customers faster. The approach you choose depends on how your team would like to work.

Let’s start with a high-level overview of the differences between Scrum and Kanban.

Scrum vs Kanban at a glance

What is Scrum?

Scrum offers a more rigid structure for working than Kanban. Projects are broken down into smaller increments, and each of these increments is completed over a predetermined block of time called an iteration or sprint. So, the goal of a Scrum team is to deliver something at the end of each sprint. This could be a feature, part of a feature, or some other kind of deliverable. At the end of each sprint, a retrospective takes place, looking at what was and wasn’t done during the sprint, and what should be improved for the next one.

How does Scrum work in Jira? Well, you will typically create a project, e.g. a marketing team will create a project called “Marketing”. Everything related to marketing will live here, including your backlog of tasks. You might then choose to create epics. Epics are used for features/deliverables that are quite large and would take multiple sprints to complete, e.g. a marketing campaign for a new product. From there, your epics get broken down into tasks, e.g. creating a brochure for your marketing campaign. When planning an upcoming sprint, your team will choose which tasks from the backlog to add to it.

You will then visualize your work on a Scrum board that shows your sprint, with columns for “To Do”, “In Progress”, and “Done”. You can also add other custom states such as “In Review” and “Ready to Publish”.

You will agree prior to the sprint which issues from the backlog to commit to completing during it, and then you’ll work on moving those issues through the columns over the course of the sprint. Not making changes in the middle of the sprint means not adding any more “To Do” items from the backlog. This would change the scope of the sprint and might mean that you’re not able to complete all the work in the allocated time.

What is Kanban?

Kanban has some similarities with Scrum in that you visualize your work on a board, in this case a Kanban board. On the face of it, a Kanban board looks much the same as a Scrum board and will typically have columns for “To Do”, “In Progress”, and “Done” through which you move your tasks. As with Scrum, you can also create more specific custom columns such as “Writing”, “Designing”, “Technical Review”, “Published”, and “Shipped”, depending on what your project or product actually is.

The difference with Kanban is that the board leads the process, whereas with Scrum, the sprint leads the process. You could argue that the board is more important in Kanban because visualization of your workflow is so fundamental. In Kanban, it’s all about looking at your board and making sure work items are moving through it at a steady pace and not getting stuck in the “In Progress” state. Kanban teams use their board to see what needs to be done and prioritize accordingly. By contrast, the work to be done in Scrum has already been decided, before you even get to the board. You could say that in Scrum, the board is used to monitor what’s happening, whereas in Kanban, the board is used to control what’s happening.

In Kanban, there are no time-boxed sprints and changes can be made according to the team’s needs. Kanban teams prioritize work by placing items at the top of the backlog and giving them due dates. While Scrum requires high control over what’s in your team’s scope, Kanban lets you change the scope as long as you don’t disrupt the continuous flow of work. Kanban teams keep control by looking at Cumulative Flow Diagrams, which help understand the number of work items in each state and identify specific bottlenecks. They might also use work-in-progress limits to cap the number of items that can be moved to the “In Progress” column. This stops tasks from getting stuck, because the limit will encourage everyone to swarm on the items that are there and get them done so that they can move forward with other work.

You can still use the same issue types in Jira, e.g. epics for larger bodies of work. It’s just that the way you work on those epics is less structured and more fluid.

Which is best for YOU?

Scrum is the better fit if:

• Your team works better with more stringent rules and processes in place

• Detailed planning is required

• There are dependencies on individuals and teams outside of your team

• Certain tasks depend on others being completed

• You want your team to be protected from scope changes while they are executing work

Kanban is the better fit if:

• You’d prefer a more flexible approach to deciding what work to do and when

• You can’t or don’t need to plan work very far ahead of time

• All of the work can be completed by your team

• Each task can be completed in isolation of others

• You want to be able to adapt to change quickly, course-correcting as necessary

You might think that your team’s philosophy sits somewhere between the two, or that neither seems like the right fit. However, there are pitfalls in trying to combine elements of Scrum and Kanban; most teams end up not really getting the benefits of either and, as such, they end up agile-in-name-only. In a future article, we’ll discuss these mixed methodologies and other agile approaches you might want to try.