Kanban vs. scrum
If you search for “Kanban vs. scrum” online, you will find a plethora of articles arguing one approach over the other. Who knew there would be such conflict and drama? Perhaps workflow selection just brings it out in people.
But comparison is a zero-sum game. Countless factors impact how well a team will adopt and benefit from a particular framework or method. The right flow for one team could be a deadly blocker for another. Choosing a workflow methodology should be a collaborative discussion between organizational leaders and functional teams.
Kanban and scrum are iterative approaches with a focus on managing the flow of work within product development. Each approach relies on processes designed to reduce waste, spur improvements, and increase the rapid delivery of working software. Neither is new, yet over the last few decades kanban and scrum have skyrocketed in popularity — especially among product development teams. You could look at this as a reflection of the effectiveness of the two methods. But realistically the interest in kanban and scrum is more directly correlated with the rapid advancement of and investment in technology.
The truth is that no matter the customers you serve or the product you sell, your company is likely producing and investing in business-critical technology solutions. This makes development a crucial part of any organization. Company and team leaders are on the lookout for proven tactics to increase productivity and reveal opportunities for improvements. Because of the iterative and incremental nature of development, kanban and scrum have emerged as two beneficial approaches.
Kanban visualizes tasks and enables continuous flow within each cycle. Scrum puts more emphasis on set timelines and assigning specific roles. Both methods are based on a pull system, meaning that you do not start something new unless you have completed the in-progress tasks.
There are no universal guidelines for choosing a workflow methodology. Skip ahead to any section to find detailed descriptions that will help you compare and contrast the two approaches:
What is kanban?
Kanban is a method for delivering high-value features. A kanban board features several vertical columns. Each column represents a workflow status, such as “In development” and “Ready to deploy.” Cards that represent work items move from the backlog through column to column, until each reaches the team’s definition of done. The goal is to set work in progress (WIP) limits for how many cards can be in each status column at any given time.
This is a kanban-style workflow board in Aha! Develop.
The benefits of kanban are simplicity and flexibility. It is adaptable to any product or project — because there are no prescribed time frames, it is particularly beneficial for development teams who practice continuous deployment. Since work is visualized on a board you can quickly see where progress is stymied. Setting WIP limits ensures that the team only ever has as much to do as they are capable of completing.
Related guides:
What is scrum?
Scrum is a process framework used in agile software development. It was founded on empiricism — the theory that all knowledge is derived from self-experience. In scrum this plays out through the reliance on self-organizing teams who focus on three pillars: transparency, inspection, and adaptation. Times are broken out into sprints, which are typically two weeks at a time. Product owners are able to understand team velocity by reviewing burndown charts from current and prior sprints.
Analyze team progress using a burndown chart in Aha! Develop.
The benefit (and limitation) of scrum is that it is a defined framework. It offers teams an explicit structure to follow. This can be particularly helpful if you are working in a large organization and want to ensure consistent workflows and practices across all groups. You can layer additional methodologies on top of scrum, but to practice scrum fully, you must rigidly adhere to the framework. There are several scrum certification programs available, as well as a handful of free and paid courses online.
Related guides:
What are the differences between kanban and scrum?
Kanban and scrum are distinct methods with important differences. The main difference is that scrum is prescriptive with a defined structure of specific rules, roles, and practices. Kanban is much more lightweight, with throughput as the main performance metric.
If you want to think about it in the simplest terms — kanban is continuous and lightweight, while scrum is fixed and process-driven. Your kanban board never ends. Work is continually pulled in as the team’s capacity allows. Your scrum board is reset at the end of each sprint. Work is planned and broken down into bite-sized user stories for completion. Both kanban and scrum put a premium on learning from empirical evidence based on actual performance.
What other differences are there between kanban and scrum? The table below outlines the basics.
Kanban | Scrum | |
Planning | No formal planning process but the number of cards allowed on the board is managed by setting WIP limits. | Planning is integral with the initial scrum ceremony being the sprint planning session — the goal is to establish what can be accomplished during the entire sprint in collaboration with the broader scrum team. |
Work estimation | Estimates are based on how long it took to complete work in prior cycles — forecasts are tightly tied to the predictability of work. | Estimates are done by the scrum team during the sprint planning meeting to right-size how much can be completed during a given sprint. |
Roles | No defined roles but some teams have service delivery and service request managers | Product owner and scrum masters/leaders, as well as the scrum team |
Rituals | No specific rituals or ceremonies, but teams are encouraged to constantly look for ways to improve the flow of work and remove blockers. | There are four defined events (sometimes called rituals or ceremonies) that occur within each sprint — detailed below under “meetings.” |
Artifacts | No predefined artifacts | Artifacts in scrum include:
|
Release cadence | Continuous | Defined intervals called sprints, with a typical duration of two weeks but no more than four |
Delegation and prioritization | Teammates can only pull new tasks onto the kanban board once the previous task is complete. | Teammates can pull tasks that have been previously prioritized and included in an active sprint onto the scrum board. |
Delivery | Continuous | At the end of each sprint, as approved by the product owner |
Change | Change can happen at any time. | Changes should not be made to the sprint forecast during the sprint. |
Meetings | There are no defined meetings but meetings are broken out by team-level (e.g. daily standups) and service-level (e.g. delivery and risk review). | There are four mandatory meetings: sprint planning, daily scrum, sprint review, and sprint retrospective. |
Performance metrics | Lead time and cycle time | Velocity and planned capacity |
Tools | Most popular workflow management tools include functionality that support kanban, and that method can always be used with a physical board and cards to represent the flow of work (such as a white board and sticky notes). | Scrum tools include functionality such as a scrum board, as well as dynamic reporting for estimating team capacity, creating burndown charts, and doing retrospectives. |
What are the similarities between kanban and scrum?
Kanban and scrum may be different methods but there are many similarities. For example, both use a board and cards to visualize backlog items and in-progress work. Both encourage daily standup meetings to monitor the flow of work and identify areas for improvements. The list below reveals additional areas of overlap between kanban and scrum:
Reliance on self-organizing teams
Emphasis on transparency and process improvement
Use WIP limits
Break large work items into smaller units
Prefer work to be pulled onto the board by the team
Prioritize delivering working software early and often
Optimize based on empirical evidence
How to choose between kanban and scrum
We all want to be more productive and deliver what matters most. So if you are charged with evaluating different workflow methodologies for your team, it is only natural to seek out expert advice to inform your choice. Product development is complex and there is no one right method for all circumstances. You know what your team’s limitations and advantages are and those should help guide your evaluation.
Newly-formed teams may be better suited to scrum adoption, since the process framework lends built-in discipline. Seasoned teams who have an existing flow and want to put a focus on continual seamless delivery may enjoy kanban. And of course, many will want to pick and choose between the two methods and may instead create their own hybrid approach.
As you reflect on what method to choose for your team, it can be helpful to understand the pros and cons of both kanban and scrum. The tables below outline the benefits and the disadvantages of both approaches so that you can discern which might be a better fit for your team.
Pros and cons of kanban
Kanban | |
Pros | Cons |
|
|
Pros and cons of scrum
Scrum | |
Pros | Cons |
|
|
Frequently asked questions about kanban vs. scrum
Are kanban and scrum considered agile or lean?
Both methods have become synonymous with agile workflows and lean principles. But it is worth noting the history of kanban and scrum to understand the agile and lean connection. Kanban is the older of the two approaches and sprung from emerging lean manufacturing processes in the late 1940s. Scrum is a more recent approach that is closely associated with agile development. It gained traction in the late 1980s before it was formally introduced by software engineers Ken Schwaber and Jeff Sutherland, both original signers of the Agile Manifesto.
Can scrum and kanban be used at the same time?
Purists will say no. After all, each method has distinct rules that inform the framework. Scrum in particular has prescriptive rules, roles, and requirements for implementation. But a one-size-fits-all approach is rarely applicable — every organization is different depending on your customers and your product. This is why many teams looking for a hybrid approach that combines the best of both methods may choose to implement so-called “scrumban.”
What is scrumban?
Scrumban does not have a single definition or prescribed rules. Instead, the term is used to capture the way that an organization might employ elements of each method that work best for them — without following either in its pure form. No two teams will scrumban the same. It is truly unique and customized to your preferences.
Is kanban easier than scrum?
Ease is relative. Kanban may be quicker to implement because it is so lightweight and has few rules. Yet this is also what can make it more challenging. People may be able to intuitively understand the process because of its simplicity, but the lack of rules can be difficult — especially when you are trying to adopt a new way of working. The paradox of freedom is that you have the burden of choice. The constraints of scrum may be beneficial to teams who crave structure and therefore easier to adopt.
When should you not use kanban?
Kanban may not be the right choice for a variety of reasons. For example, your development team might be a shared resource or your product team might struggle with creating consistently sized stories. Internal dynamics can create tension as well — since there is not a prescribed hierarchy in kanban you need to have open and engaged teammates who are committed to the process at every level. Lack of strategic planning is a common reason that teams abandon kanban. Remember that kanban is simply a method for getting work done. It does not contain any guidance about why you are working on something, what it should do, or how it should be implemented.
When should you not use scrum?
If your environment is relatively simple then scrum is likely not the right choice. Complexity is one of the reasons that teams choose scrum — if your organization and what you are building are sophisticated. If you anticipate needing to respond to change more quickly than a sprint time frame allows, scrum should not be used. Similar to kanban, scrum adoption may languish if teams are not empowered to self-organize and self-manage or if folks are unable to accept the results of empirical feedback loops.
What tools do teams use for kanban and scrum?
Best-in-class product development software will include functionality that supports kanban, scrum, and other workflow methodologies. There are plenty of tools on the market that support the approaches outlined in this guide. But the tool itself is not the lynchpin for a successful implementation of kanban or scrum — it is the people who are doing the work. Embracing a new flow can be a direct affront to established processes and even challenge the way that people think about what they do. Both approaches put an emphasis on self-organizing teams and continuous improvements, which can shine a light in dark places that have otherwise gone unnoticed. If you are confident of your organization's commitment to a successful kanban or scrum implementation, then you will want to look for agile development tools that offer maximum flexibility and will allow you to scale and adapt over time.
Productive and happy development teams use Aha! Develop to customize the way they work. Sign up for a free 30-day trial to discover all you can do with this fully extendable agile development tool.
