Scrum vs. Kanban: Which Agile Framework Is Best?
Once your team decides to adopt Agile for managing project delivery, the next challenge may be deciding which framework is best. Scrum and Kanban, the two most common Agile frameworks, are each an iterative work system that focus on reducing waste. Each has strengths that may make them a better option for your team, as well as disadvantages that might rule them out. In this article, we’ll evaluate the pros and cons of Scrum and Kanban. Then we’ll assess how to identify which methodology aligns to your current needs in terms of delivery, team dynamics, customer requirements, and business impact.
Scrum vs. Kanban: comparing key differences
Scrum and Kanban are each a framework that teams can use to define roles and responsibilities, structure deployment, release cadence, and company metrics.
Roles and Responsibilities
Roles and responsibilities differ significantly between Kanban and Scrum.
In a Scrum team, the roles are clearly separated and defined, each with its own tasks and responsibilities:
• Scrum Master
• Product Owner
• Developers
The primary advantage of this approach is that it allows teams to work in a more structured dynamic. However, if change is a constant factor or frequently changing business requirements mean you need the ability to rapidly adapt, a Scrum approach can be a disadvantage. In a Scrum team, the sprint backlog needs to be reviewed, refined, and approved by the Product Owner, Scrum Master, and developers. If the backlog is changing on a daily basis, it can mean a less responsive team.
This is a crucial difference to Kanban, in which all the team members are identified as leaders, and they all own the Kanban board. Kanban gives teams free will in terms of work assignments, allowing them to focus more on how to get the work done instead of who will do it. The disadvantage is that Kanban boards can get complicated. Everyone owns the board, and there are no roles assigned to work on specific updates. To make Kanban work, the team needs to pay careful attention to the board flow since it’s a reflection of the team’s deliverable.
Structure Deployment
Scrum uses timebox intervals called sprints as a point of reference in prioritizing tasks assigned during the sprint planning process. This level of commitment helps teams to focus on the corresponding priorities for the duration of the sprint, which is typically two weeks. Setting deployment at the end of each iteration gives the team time to focus on their assigned task. It is also valuable for the stakeholders to see the constant improvements. However, if the team has dependencies with other teams and their sprints are not aligned, the release cadence can become a recurring and sometimes inefficient discussion of priorities and roadblocks. To avoid this, Scrum teams must be aware of their dependencies and how they could affect the team’s delivery.
On the other hand, Kanban uses a continuous workflow structure, in which the work is prioritized and moved across a board for the project duration, normally using columns such as To Do, In Progress, In QA, and Done. This flexibility helps the team to focus on what is urgent and what is important at the same time. Another advantage is that it’s not dependent on other features. A disadvantage that some teams struggle with is that too much flexibility can be transformed into too many features that are being worked on and not enough features being completed.
Cadence of Events
Scrum’s five events, called ceremonies, are well defined and describe the outcome expected for each:
Sprint: The timebox defined in which all the ceremonies happen. The sprint is sometimes referred to as “the heartbeat of Scrum.”
Sprint Planning: This is the first step of each sprint, in which the team defines the work to be achieved and answers the questions: Why is this sprint valuable? What can be completed in this sprint? How will the work get done?
Daily Scrum: A daily meeting in which team members answer three questions: What did they work on yesterday? What will they be working on today? Are there any roadblocks to achieving that work?
Sprint Review: Here, the Scrum team presents the results of the sprint. Stakeholders and Product Owners provide their feedback and approval in terms of the sprint goal.
Sprint Retrospective: An introspective review of how the last sprint went, which teams can use to reinforce the things that went well, identify areas for improvement, and propose action items for those improvements.
This Scrum event cadence can be helpful in keeping teams organized. You can use the ceremonies to understand the scope of a sprint, redefine priorities, and clarify doubts before the team starts work on their task. However, if your roles and responsibilities are not well defined beforehand, your team can become confused and less productive. This can also impact the scope of each team member. To ensure the best outcome, the Scrum Master must have previous experience with Scrum, since she will be leading the ceremonies and helping the rest of the team to apply the framework.
Kanban, on the other hand, uses six core practices to guide implementation:
Visualize the work: The Kanban board makes the process highly visual, and can be thought of as the heart of Kanban, much like the sprint is to Scrum. The primary visualization is a board with cards and columns, which becomes the orchestrator of how work flows.
Limit work in process: This rule helps teams to focus on one thing at a time. By limiting the amount of work in each column, the team avoids bottlenecks and ensures work is constantly progressing from one column to another.
Manage flow: A Kanban team wants work to flow as fast as possible to the customer, while ensuring maximum quality. Kanban teams don’t focus on managing people, but instead on managing the processes and system to enable the most rapid flow.
Make policies explicit: Within a high-functioning Kanban team, policies are simple, well-defined, visible, always applied, and readily changeable by those providing the service.
Implement feedback loops: The only way to improve is to identify improvement areas. Feedback loops or spaces help teams to communicate about how the project went, identify areas where they think they can improve, and propose actions to improve them.
Improve collaboratively, evolve experimentally: The heartbeat of Kanban is continuous improvement. The key is communication and collaboration between team members, to identify, keep, and nurture useful changes and to reject ineffective change.
Because it focuses so much on communication and collaboration, Kanban may not be ideal for organizations that aren’t open to working with high levels of autonomy, skipping hierarchical levels, or promoting bilateral communication.
Metrics in Scrum in comparison to Kanban
You can’t improve what you don’t measure. Scrum and Kanban metrics are different, and this may influence which approach you choose.
Scrum focuses on velocity, defined as the average amount of work a Scrum team completes during a sprint. This metric compares Commitment, which shows the estimated work the team is expected to deliver and Completed, which reflects the real quantity of work completed by the end of the sprint.
Velocity is perfect for teams that need to understand their cadence of delivery. The main goal is to establish a comparison between Commitment and Completed, since this will reflect the team’s ability to accurately estimate and allocate work within a sprint. It will also help to identify how frequently the scope of the team is affected.
If the scope of the sprint changes, or the number of team members changes constantly, the velocity of the team will be impacted. To avoid this, the team must keep the sprint backlog stable during the sprint, accepting minimal or even no changes. For teams that typically accept frequent backlog changes, this can be a disadvantage.
Kanban typically focuses on Lead Time, or the time from when a new task is requested until it is complete, and Cycle Time, or the time from when someone on the team starts work on a task until the task is completed. The Cumulative Flow Diagram compares these metrics to illuminate how stable the work flow really is.
In Kanban, Cycle time and Lead Time track how tickets behave in the flow. Bottlenecks are always a concern when we apply Kanban, so understanding where they could happen can guide you to areas for improvement.
A disadvantage of Kanban is that if you don’t constantly update your board, making items move across it, you can’t accurately measure your team’s improvements. If you’re committing to Kanban, you must also commit to maintaining the Kanban board.
Scrum vs. Kanban: the choice is yours
To help you as you evaluate the Scrum and Kanban frameworks against your team’s needs, we’ve summarized the key aspects of each in the chart below…
At the end of the day, Scrum and Kanban are just frameworks. Each team should adapt and evolve whichever framework they choose according to their team and business needs. Some teams implement one or the other. Some implement a mix of frameworks.
