While this article is titled “Kanban vs Scrum”, our intention is not to battle the two methods up against each other, but instead, detail the similarities and differences so you understand the best circumstances of when to use either method.
So, without further ado…
What is Kanban?
Kanban is a scheduling system that visualizes the workflow process and the work passing through. Part of Lean and Just-in-time (JIT) manufacturing it was derived from the manufacturing industry by Toyota employee, Taiichi Ohno, in the 1940s. Since then, Kanban has evolved into the visual scheduling system that many of us are familiar with today.
The Kanban method aims to reduce waste, continuously improve the process, and increase overall productivity. While there are no established rules of how Kanban works, there are six general practices that should be applied to ensure optimized Kanban use. They are:
- Limit work in progress
- Flow management
- Make policies explicit
- Use feedback loops
- Collaborative or experiment evolution
The visual nature of Kanban allows you to identify any bottlenecks early on in the development process, enabling you to deliver a higher quality product. It does this with the help of Kanban tools such as a Kanban board, Kanban cards, and sometimes even Kanban swimlanes.
A Kanban board is what is used to visualize the development process. A typical board features at least three columns, titled “To Do”, “Doing”, and “Done”, which represent various stages of the process.
The board can either be made with a whiteboard, sticky notes, and markers, or you could use an online Kanban board, for which there are endless software options.
Kanban cards are what are used to depict a work item or task within the work process. It can also represent information such as the item/task’s status, cycle time, and deadline.
Not every Kanban board uses swimlanes. Swimlanes are a visual element on the board that flow horizontally and are used for added organization. They categorize items or tasks and enable you to further distinguish them.
What is Scrum?
Scrum is an agile framework which focuses on developing, delivering, and sustaining complex products through collaboration, accountability, and iterative progress. It encourages collaborative decision making and constructive feedback so a higher quality product can result.
Scrum is known for its defined team roles which are self-organizing and cross-functional, and designed to optimize flexibility, creativity, and productivity. They are:
The first role is the Product Owner who is the product expert. They represent the stakeholders and the voice of the customer. They are solely responsible and accountable for managing the Product Backlog.
The Development Team is a group of professionals who deliver the product and create the Increment which is the working product functionality that is presented to the stakeholders and the of the sprint and could potentially be given to the customer. It usually comprised of developers, programmers, or designers.
The Scrum Master facilitates a scrum project. Their core duty is to ensure the team successfully executes the project according to the principles and practices of scrum methodology, and that everyone on the team understands the core aim of scrum.
They are responsible for making sure the development team is on track by providing necessary resources and blocking out any distractions that may hinder the development process.
A scrum workflow is made up of events. Each event is time-boxed, meaning they hold a maximum duration time that cannot be exceeded.
Sprints are iterative time boxes in which a goal is accomplished. The time frame doesn’t surpass one calendar month and is consistent throughout the development process.
This event happens at the beginning of every sprint, and it’s when the scrum team gets together to plan the upcoming sprint.
A Daily Scrum is a 15 minute time boxed meeting that happens at the same time, every day of the Sprint. The team discusses the previous day’s achievements as well as the expectations for the next day.
A review is an informal meeting held at the end of every Sprint. This is where the Scrum team present their Increment to the stakeholders and discuss feedback.
The Sprint Retrospective occurs after the Sprint Review and before the next Sprint Planning. It’s a meeting where the team consider the steps and actions of the previous Sprint and set up improvements for the next Sprint.
This is where all the requirements needed for a viable product are listed in order of priority. It includes features, functions, requirements, enhancements, and fixes that authorize any changes to be made to the product in future releases. It’s managed by the product owner.
This backlog is a list of the tasks and requirements that need to be achieved during the next Sprint. It is sometimes accompanied by a Scrum task board that is used to visualize the progress of the current Sprint.
A user story is a tool used to describe a software feature from an end-user perspective. They help to imagine the type of people that would use the product. The common format that is used to initiate discussion and thought is:
As a [role], I want [feature], because [reason].
The product increment is the result of all the product backlog items accomplished during a sprint. It’s the working product that is presented at the end of the sprint to stakeholders and potential customers.
Kanban vs Scrum
Kanban and Scrum are both iterative work methods that aim to reduce waste. While they both adhere to the agile principles of collaboration, continuous improvement, and flexibility, you can see that Kanban and Scrum are their own methodologies. Their main differences include:
|Roles||No fixed roles||Scrum master, Product, Owner, Development Team|
|Changes||Not restricted, allowed to happen at any time||Not recommended during the sprint|
|Key metrics||Cycle time||Velocity|
|Delegation & Prioritization||Pull system workflow where items/tasks can only be "pulled" once previous has been completed||Pull system also used, but a whole bunch of items/tasks are pulled for each iteration|
To dive deeper into the last point, a key difference between Kanban and Scrum is the workflow and how items are managed. In Scrum, the work you do during a sprint is determined before the sprint starts. Then you do all the work during the sprint and after a few weeks (no longer than a month), your queue is empty.
In Kanban, only the size of the queues is limited, known the WIP (work in progress) limit. This means there are no time restrictions as to when you are able to change the items in the queue, and there’s no such thing as a “sprint end”. This allows the work to continue flowing.
Kanban is a tool that can be used to visualize project workflows to improve performance and quality. It doesn’t have a strict set structure in place, so it can be used with whatever process your team has already implemented. It can even be applied to personal productivity purposes.
Scrum, on the other hand, is iterative and incremental which means it’s ideal for teams who want a more enforced method of working. It’s also more suitable for teams with less than seven people.
Can Kanban and Scrum be used at the same time?
Kanban and Scrum can be used at the same time, most commonly by Scrum teams using Kanban. This method is known as “Scrumban”.
Scrumban is a workflow management approach that takes the structure of Scrum and combines it with the flexibility and the visual representation of Kanban. It can be used for teams who want to apply Scrum project management as a way of working and adopt the Kanban method as a way to visualize and continuously improve.
This method can also be used as an avenue for teams seeking to transition from Scrum to Kanban. Software development teams who may find an immediate shift too extreme can turn to Scrumban as it offers an easier transition period for teams. An example of the kind of projects Scrumban could work well for are maintenance ones such as a help desk or support assistance.
In conclusion to the Kanban vs Scrum discussion, it’s safe to say that they are different methodologies that appeal to different audiences. Where Scrum favors a more prescriptive process, Kanban leaves room for a more flexible workflow.
They both comply with agile principles but also have their own individual values and practices. Which side of the fence you sit on when it comes to Kanban vs Scrum really comes down to the kind of project your team has and what type of product you wish to deliver.
Have you used either Kanban or Scrum lately? If so, don’t forget to share your experiences in our comment section. We appreciate any feedback we get as it helps us to deliver the kind of content our readers wish to see!
Dinnie and the Zenkit Team