What is the difference between Scrum, Kanban and Scrumban?

Being Agile is becoming more and more of a big deal for long-term company success. And though it may have started with software development back in early 2000 (in theory), today, it’s a bit more than that. 🚀

Agile is a fairly logical approach to project management; fundamentally, it’s about becoming more adaptive and being able to respond to change quickly. And though there are various ways to approach Agile development; Scrum and Kanban are pretty much the two most popular ways to go about it.

Both Scrum and Kanban methodologies have their advantages, but at the end of the day, no methodology can be separated from context: your team and the products you’re building.

What is Scrum?

Scrum is a framework based on lean thinking and designed for developing and maintaining complex products. Scrum describes a set of meetings, tools and roles that intertwine to help teams plan and manage work.

Scrum, like any Agile methodology, uses an iterative, incremental approach to predict and manage risk by engaging people. After all, Scrum is a framework that helps teams work together better.

Why is Scrum so popular?

While it seems that Scrum is made for software development teams, its ways and principles can be applied to countless types of teamwork; it’s one of the reasons Scrum is so popular.

Where does the name for Scrum come from?

Scrum gets its name from rugby; yes 😁 and it has a really interesting story actually; here’s if you want to know more about Scrum’s connection to rugby.

What are the Scrum pillars?

Scrum is based on 3 pillars: transparency, inspection and adaptation. Fundamentally, Scrum is about looking at progress in a way that is pragmatic (as opposed to building fictitious plans) while inspecting things along the way and making changes as per the need; all the while shifting the culture towards Agility.

1. Transparency

Everyone involved in doing the work and those who benefit from it should have full visibility over work and process.

2. Inspection

To detect problems early on, product backlog, sprint backlog and increments progress (or as we call them Scrum artifacts) should be inspected often.

3. Adaptation

Without adjustments being made quickly to minimize the losses, inspection can be useless. Adaptation is easier when people self-manage.

What is the Scrum process?

In the Scrum environment, the Scrum master is boss; they basically host the work space.

The process is simple:

1. The product owner organizes the work for the product backlog, then prioritizes backlog items with the team.
2. Collaboration happens with the Scrum team to create a sprint plan.
3. Developers pick the product backlog items they want to include.
4. Backlog items are turned into increments of value, valuable work produced by developers during a Sprint.
5. When the work is done, the Scrum team and stakeholders inspect the results, adjust, then adapt for the next sprint.
6. Process is repeated.
   

What is the Scrum framework?

The Scrum framework is incomplete (on purpose) and built upon by the people using it; countless processes and methods can be used within the space. The framework works around current practices to make them better, or simply bypasses them.

I recommend that you reference The Scrum Guide if you want to know more about Scrum. Also, for an overview of Scrum-related terms, this is the Scrum Glossary.

What is a Scrum team?

The Scrum team is made of a Scrum master, product owner and a number of developers, typically 10 or less people. There are no hierarchies or sub-teams within a Scrum team, and everyone has one objective at a time: the product goal. People self-manage which means that they internally choose who does what, when and how.

If you’re interested in knowing more about the Scrum team and how things work in detail, here’s the article for it.  

1. Developers

Developers create the plan for the Sprint and Sprint backlog.

2. Product Owner

The Product Owner manages and prioritizes the product backlog, then communicates the product goal.

3. Scrum Master

The Scrum Master establishes Scrum within the organization, and is responsible for how effective a Scrum team is.

What is a sprint?

The Sprint is the central piece of any Scrum; it’s where ideas turn into something valuable. A Sprint has a fixed length of one month or less, starting right after the last Sprint finishes, and it encompasses everything you need to achieve the Product goal; that includes sprint planning, daily scrums, sprint review, and sprint retrospective.

Sprint Planning

Sprint Planning is the first step in any Sprint; it’s where you lay out the work to be performed, resulting in collaboration of the entire Scrum team.

Daily Scrum

The Daily Scrum is a 15-minute event for developers and the Scrum team, where we look at the progress toward the Sprint goal and adapt the Sprint backlog accordingly.

Sprint Review

The Sprint review is where the Scrum team presents the results to key stakeholders, the Product goal gets discussed, and where we inspect the outcome of the Sprint and see how to adapt to changes.

Sprint Retrospective

The purpose of the Sprint retrospective is to see how to increase quality and efficiency. This is where the inspection goes as to the last Sprint, with regards to people, process, interaction, tools and so on.

Now, when it comes to Kanban vs. Scrum, we’re talking about two strategies to implement Agile. While Scrum is based on short, structured work sprints, Kanban is more continuous as a methodology.

With respect to their principles, both Scrum and Kanban are pretty much the same; it’s in how they implement Agile that makes the difference.

What is Kanban?

Kanban is an Agile way to visualize work and mazimize efficiency by reducing the time it takes to take a project from start to finish. It’s a systematic, lean way to work in teams by pulling Kanban cards (work items) through an actual process that ensures continuous delivery.

The Kanban method is designed to cut into bits and pieces, any complicated problem with interdependent workflows, and visualize those bits on a shared board in real-time. It helps align priorities among the team while maintaining focus.

How did Kanban start?

Kanban came about as a scheduling system for Toyota’s lean manufacturing processes in the late 1940s. Back then, the standard approach was to produce goods then push them onto the market, instead of producing goods based on customer demand (like in the case of Toyota).

As a concept however, it came about via Japanese businessmen who learnt from American supermarkets; where restocking was happening according to shelf space available, rather than supply. This enabled them to prevent waste and the loss of item value over time.

To draw a parallel; if a team is using the Kanban method, then the action of, say, moving a feature release into “done” would signal for the beginning stage of the next feature, assuming a limited supply of capital (which is pretty much always the case).

What does Kanban mean?

The Japanese word “kanban” translates to “visual board” or “sign”, and has been used to describe a workflow management method since the early 1960s. Kanban is all about helping visualize work and goals, with maximum efficiency and persistent growth.

Today, many brands choose to use the kanban method for their operations.

What are Kanban fundamental practices?

Kanban implementation is complete once all Kanban practices are followed:

• Visualize workflow
• Apply WIP limits
• Measure and manage flow
• Keep process explicit
• Know when and how to improve the process

The strength and popularity of the method lie within a teams’ ability to apply this without having to do major changes to the current process.

How to choose the right Kanban?

Similarly to Scrum, Kanban varies based on the type of work and capacity to produce sustainably. There are 6 main types of Kanban systems: production, withdrawal, supplier, emergency, express, and through; they can be identified by answering the following 6 questions:

• What is the size of the work?
• What is the type of activity?
• Is it important/urgent?
• What happens if I don’t deliver, or if I deliver late?
• Who’s requesting the work?
• What impact does this have on other people?

How to implement Kanban?

There are six core practices that must be kept in place in order to successfully implement the Kanban method; and while doing it perfectly is great, keep in mind that it’s an evolving process that constantly adapts:

Visualize your workflow in a board

Each column on the board represents a step in your workflow, and each card in your columns is a work item. The Kanban board is a visual representation of the state of your workflow, that allows you to track progress and notice issues that may include some risks or affect your production line.

Limit Work in Progress (WIP)

As mentioned before, one of Kanban’s key ideas is working with a manageable number of items, not more. If there are no WIP limits, then it’s not Kanban.  What you can do is set a maximum number of items per column (stage) to control that aspect.

Manage the flow of work items

Kanban is supposed to offer a seamless flow of production, so instead of micromanaging people by ensuring they’re constantly busy, try to understand how to create value faster by observing the work and how it goes through the process.

Define your process well

In order for people to associate and participate in something they believe is useful, the process should be clearly defined and communicated to them. When everyone is aligned with respect to the goal, they work better together.

Implement feedback loops

Agile is all about feedback loops; they ensure adequate response to change. Kanban encourages the use of feedback loops within the team, and something they call as service-oriented cadences which are reviews aimed at improving the delivery of services by understanding blockages. Kanban cadences are similar to Sprints; but their ideal duration depends on context, team size and topics.

Improve continuously

The way to achieve that is through collaborative change, based on actual data, metrics, feedback. Every hypothesis should be tested in order to improve all the time.

Why do teams adopt Kanban?

Get better visibility of the workflow

Kanban is all about bringing transparency to the process, by having the ability to visualize every work item in a board where all tasks are visible.

Improve workflow for faster delivery

Kanban allows project managers to closely monitor the distribution of work; they get a good view of the items completed, the stages they’re in and the bottlenecks. Teams are better able to tackle challenges so they can improve their workflow - which means higher delivery rate.

Align goal with your day-to-day

Company strategy is aligned with day-to-day activity thanks to transparency, continuous feedback, and regular review meetings. This alignment leads to more agility, allowing teams to change priorities based on market or customer needs.

Forecast and manage dependencies

After you’ve started accumulating work items on your Kanban board, you’ll be able to understand the work process better and forecast delivery more accurately, by analyzing how long a task spends in your workflow. You will also be able to map and manage dependencies, giving you full transparency.

Reduce waste output

Kanban as a method implies that the work is done only based on demand, not supply. This helps you reduce waste by focusing on the tasks needed in the present, as opposed to some backlog of tasks that may or may not get you somewhere.

What are Kanban designated roles?

Unlike Scrum which is very specific about roles, Kanban is way less defined. But the following roles will probably show up in most implementations:

• Service Delivery Manager who will work on flow and change management and make sure improvement and delivery are ongoing.
• Service Request Manager who will act as a medium, bringing client needs to the team.  

The Kanban method is not only transparent, but also constantly open to feedback and change; it helps businesses align with their customer needs and allows them to respond better and faster.

How does Kanban differ from Scrum?

What is Kanban vs. Scrum?

Scrum is a process designed to help deliver business value in the shortest amount of time through continuous iteration. It emphasizes teamwork, and aims to deliver new software every 2-4 weeks.

Kanban is a system built to help manage work smoothly, at optimal speed, by visualizing both the process and the actual work. It helps identify bottlenecks in the process and fix them continuously.

Why use Kanban vs. Scrum?

Scrum deals with complexity by making information transparent, while allowing teams to respond easily to sudden change and adapt along the way.

Kanban methodology is great for improving throughput, time and quality by continuously making small changes to the process.

When to use Kanban vs. Scrum?

Scrum is used in projects where the requirements are either unknown at the start or bound to change fast, and where cross-functional teams self-manage. Change is central to Scrum, whether we're talking product, requirements or processes.

The Kanban method is great for teams who wish to optimize an existing process that already works, by visually understanding progress as well as project complexities like processes and risks.

Scrum board vs. Kanban board

Scrum boards require more preparation given they’re more methodical in nature, whereas Kanban boards offer less structure but more leeway.

Both Kanban boards and Scrum boards use categories of sticky notes to communicate progress; be it a new feature, task, bug, tech requirement, change request or knowledge acquisition.

Also, both Kanban and Scrum boards use columns like “to do”, “in progress” and “done” in a non-canonical way, meaning they can be changed according to the needs of the team.

Scrum vs. Kanban in Jira

Jira comes with project types dedicated to both Scrum and Kanban. These guides can help you get started: how to do scrum with Jira Software and how to kanban with Jira Software.

Scrum vs. Kanban - the general consensus

Who’s responsible?

Scrum: the Scrum team owns the Scrum board (run by the Scrum master) and is responsible for all tasks.

Kanban: no specific team owns the Kanban board, whereas each person is responsible for their own steps in the workflow.

Who can edit the board?

Scrum: only the Scrum team (not the Product manager) can edit the Scrum board once the team commits to Sprint items.

Kanban: anyone can edit the Kanban board, including the Product manager.

What is work in progress?

Scrum: the dev team commits to a certain number of tasks during a Sprint; all tasks can be “in progress” at the same time.

Kanban: work in progress (WIP) is limited as per the agreed-upon workflow.

What happens to tasks at the end?

Scrum: at the end of each Sprint, all tasks are put into the “done” section then cleared from the board.

Kanban: given there are no timeframes, the flow continues with the project life cycle.

Can you make changes half way?

Scrum: Scrum board items are set during the planning session; no new item can be added during the Sprint.

Kanban: limits to WIP ensure a new item is added to the Kanban board every time a task moves to “done”.

How are emergencies dealt with?

Scrum: the way Scrum is set up makes it rare that a Scrum team faces unexpected problems; the whole point of Scrum is that it’s predictive.

Kanban: a team can add a whole column for emergency tasks if they want to.

How flexible is the backlog?

Scrum: the team will move items from the product backlog to the sprint backlog in the form of user stories.

Kanban: user stories aren’t a must; but when used, they’re the most flexible user stories (in all Agile methodologies) given they can be moved back and forth by the Product manager.

How big can a task be?

Scrum: if a task is too big for a Sprint, it is split into steps; some of which can be completed within the next Sprint timeframe.

Kanban: there is no rule regarding the volume of a task in Kanban.

What is the difference in prioritization?

Scrum: prioritization is important for organizing the product backlog, then Sprint backlog.

Kanban: forecasting is more at play here; no real prioritization or estimation.

What kind of reports are used?

Scrum makes use of various reports: sprint burndown chart, epic burndown, release burndown, sprint report, version report, epic report, velocity chart, and version report.

Kanban: no specific charts are used in Kanban.

If Scrum is a framework that helps teams work more productively, and Kanban is a visual system that allows you to manage work as it goes through a production process; isn’t there a way to put these two together? Yes, there is and it’s called Scrumban.

What is Scrumban?

The Scrumban methodology is a hybrid of Scrum and Kanban, built as a way to transition from one into the other. The method combines the best of both agile methodologies, resulting in a system that is set up with Scrum (to some extent), but uses the improvement process of Kanban boards. With Scrumban, teams can continually optimize their processes as they adapt quicker.

What is the Scrumban process?

1. Create the Scrumban board
Scrumban is cyclical. The Scrumban board can include the product backlog, sprint backlog and workflow stages; whatever the team decides on. If there are no more cards on the board, then some of them can be pulled from the product backlog.

2. Agree on limits for work-in-progress
Scrumban doesn’t have story points; it has WIP limits instead decided upon as a group. The ability to plan and change the workflow at any point throughout the process is a key benefit of Scrumban.

3. Prioritize tasks with the team
The prioritization process in Scrumban is continuous and decided upon by the team. Everyone is allowed to choose what they’re working on.  

4. Hold daily stand-up meetings
Every day, based on the cards on the board, team members decide what to work on; there’s a lot of flexibility given tasks can be re-prioritized based on everyone’s workload.

How does the Scrumban methodology combine Scrum and Kanban?

The essence of Scrumban lies in the synergy between a well-defined Scrum structure and the fluid nature of Kanban workflows.

Scrumban vs. Scrum

Just like Scrum, Scrumban is all about figuring out how much work can be done in a sprint while prioritizing the most important tasks to focus on next. Of course, analysis is required beforehand.

Scrumban vs. Kanban

Scrumban uses kanban boards (referred to as Scrumban boards) in order to improve the process and visualize the workflow. Scrumban teams are also less defined (just like Kanban) and will use the WIP/pull system to ensure a continuous workflow and increased productivity.  

Moreover, Scrumban analysis allows for shorter lead times like in Kanban, as opposed to processing entire batches like the ones used in Scrum. Flow diagrams are used to showcase weaknesses in the process.

What are the advantages of the Scrumban methodology?

Scrumban saves time

There’s no sprint planning in Scrumban; plans are made based on demand (as per the WIP).

Good for compartmentalizing work

Scrumban is really good for larger projects where deliverables are set over months (if not years). In order to better manage long-term, Scrumban is divided with respect to time and prioritized in shorter iterations.

Find bottlenecks ahead of time

Bottlenecks are the bane of projects. They slow down work, mess with schedules and waste time and money. A Scrumban board helps you find the bottlenecks in workflow; those tedious tasks that slow everything down and mess with time and money.  The Scrumban board (just like a Kanban board) allows you to manage bottlenecks early on.

Be independent, autonomous, free

In Scrumban, there’s only one planning meeting; the remaining rules are fairly straightforward. Teams are given the autonomy to choose and manage their own tasks while always being able to see where the project is in terms of workflow.

What are the disadvantages of Scrumban?

As with everything, there’s always a down to the up.

1. Tasks can sometimes prove hard to track in the Scrumban board given teams can choose their own.
2. There are no daily scrum meetings which means less control for the project manager who has to communicate progress with stakeholders.
3. There are no best practices to guide you into the Scrumban methodology; it’s quite new.