Kanban vs Scrum
Kanban and Scrum are two of the most popular frameworks for Agile software project development. A Kanban vs. Scrum comparison would show how these two differ in a lot of ways, specifically, their background and their approach to meeting the project requirements. There are developments which use one or the other for specific reasons, and still others which use one for the procedural framework but borrow tools from the other.
Agile advocates and users are of the opinion that there should not be any comparison between these two. They both have their uses and their tools. These are two different frameworks which both follow the concepts and principles of Agile. For the most part, hardcore followers of Kanban and Scrum have an “us against them” attitude, which the term “Kanban vs. Scrum” denotes. However, Agile advocates understand that one is just as strong as the other and that there are conditons where one is better.
It is interesting to note that both these frameworks adhere to the tenets of Agile, and yet they are conceptually opposed to one another. They are not polar opposites, but the projects that they are best at rarely overlap. At the same time, the non-users would find it hard to understand how these two opposing points of views would follow the concepts of Agile.
Kanban and Scrum came from different disciplines. Although Scrum was first discussed as a manufacturing solution and methodology, it was first implemented on a software project. On the other hand, Kanban started out not as an Agile software methodology, but as a Lean manufacturing methodology. Any comparison between the two has to take these into account, not only for comparison purposes but also for a better understanding of the methodologies themselves. At the same time, the role of Agile in comparing Kanban and Scrum should also be considered.
Unlike Waterfall project management, which is strict, structured and formal, Agile is now less of a project management tool, but a mindset. Agile does not follow the structured software design and development strategies and methodologies of traditional waterfall project management. Instead Agile is a philosophy behind a way of doing things. Practitioners consider Agile as a mindset and use its concepts in everyday life. It is easy to see these concepts when plotting and during a road trip, or in having a picnic, or even in doing the daily commute.
Agile affords its users flexibility to add features in the software which were not included in the original project requirements. It features continuous improvement of the software development process, the product design, and the product requirements. Agile tries to address the disadvantages of waterfall project management and presents a core values to solve for these disadvantages.
Kanban vs. Scrum – Similarities and Differences
Kanban and Scrum are both Agile process frameworks. Both follow workflows which result in early product delivery, iterative product improvement, and responsive change management. Both are self-organizing, and have mechanisms to continually improve their processes. They also address the major shortcomings of traditional waterfall methodologies.
Scrum: a Quick Overview
Scrum is a procedural framework for Agile. It puts Agile concepts into a working system of continuous iterations, early and repeated product submissions and an emphasis on commitment and time management.
At the core of Scrum is the acknowledgment that time is the most important resource. It also takes into account that a project is “discovered” as it is being developed. What this means is that the software development project does not need to have a complete requirement phase because other requirements will be found and added as the project moves forward.
Kanban: a Quick Overview
Kanban is a project management approach which started out as a manufacturing process. It was meant to improve assembly line processes in the factory. It is a Lean management process where there is continuous improvement of the assembly line with a built-in quality assurance process.
It is important to remember where Kanban started in order to better appreciate what it can do for a company. Kanban, as a management approach is intent on improving the processes. Its most prominent feature is the billboard. Its core feature is the board visualization which shows the tasks completed, the work in progress (WIP) and the to-do list.
Kanban is an iterative process where self-improvement is part of the process. Its premise is an assembly line where there is no strict deadline. Instead, the key is to have a limited number of items on the WIP chart. With less tasks concurrently in progress, quality can be improved, and development can be done faster. The tasks are only included on the WIP when some other task has been removed or completed.
What are the Similarities between Scrum and Kanban?
Even though Scrum and Kanban are very different, they do share the Agile mindset. Both have procedures to introduce change into the development. Agile acknowledges that the project specifications are incomplete and that the project end is initially unknown. With both Scrum and Kanban, there is a procedure where the revisions are introduced in the workflow. For both, there is an emphasis on quality delivery, with frequent updates. Within the process, the team members are self-organizing and they have the flexibility and responsibility to correct their processes. Scrum teams can also define what “done” means.
What are the Differences between Scrum and Kanban?
As mentioned above, Scrum and Kanban started out from different roots. These origins still reflect on the current ways that Scrum and Kanban are used. Kanban is process oriented due to its manufacturing assembly line origins. Scrum has a software development viewpoint which aims to solve waterfall development’s disadvantages.
Kanban’s Continuous Flow and Scrum’s Sprint
Scrum is very much dependent on the sprint. Once the project starts, everything about the project is dependent on the small time frame of a sprint length. The recommended length of a sprint is two weeks, including the Sprint planning meeting and the development. At the end of the sprint, there is the sprint review meeting as well as the sprint retrospective meeting. The cycle starts all over again with a new set of priorities under the product backlog list.
Kanban is not as strict when it comes to the development process. From the project start to the end, it has a continuous flow of work. The tasks move from one Kanban board status to the next. Looking at the board, it can be said that the project ends when all the cards have left the Kanban board or have been moved to the “done” column.
Kanban’s Work In Progress
When people think of work or an assembly line, they think of what is being done at the moment. In any given workgroup, there is always work being done, in some, these are assigned tasks which have to be finished according to a schedule, and it is common to have additional work added to these tasks.
In Kanban, the priority is to have the process running and to produce a quality product. To ensure quality, only a limited number of tasks are done at any one time. This is determined by the work capacity of the group. If the group cannot take on more concurrent work, then these are not started. When a task or work is done and is no longer on the pipeline, only then is new work started and included in the WIP chart.
Strictly speaking, Scrum does not have a WIP chart, only the scrum chart. It contains all the information about the backlog fpr the current sprint.
Traditional structured design and development failed largely in meeting deadlines and costs. Scrum addresses the deadline problems in many ways. One of which is timeboxing. Scrum timeboxes everything resulting in short meetings. An example is the daily scrum which is a 15-minute standup meeting preferably beside the scrum board.
The development is centered around the sprint, which is recommended to be two weeks long. Deliverables are determined according to estimates of what can be done or finished within 2 weeks. The amount of work or number of sprint backlog is tied to the capability of the development team to finish something in two weeks. Iteration time is limited to the length of the sprint. As an Agile framework, Scrum is flexible about the length of a sprint and can adjust the length of succeeding sprints.
Kanban does not have a strict development time. Instead, it limits the amount of work being done at any given time.
Scrum’s Product Owner
One seldom mentioned difference between Scrum and Kanban is the role of Product Owner.
The Product Owner is one of only three roles in Scrum. It also happens to be a role which can be filled by a member of the project team or by the customer. In many instances, the Product Owner is analogous to the counterpart or client project manager in a traditional structured project management methodology. The product owner is the only point of contact between the team and the rest of the world. He introduces revisions to the product, as well as keeps track of the backlog and done deliveries. At the end of the day, the product owner is the only person who can say that the product is “done.”
This role does not exist in Kanban because there is no product owner or champion within the process. The whole team acts as the process owner but not the product owner. They are intent on improving the process, and in so doing, the product would also improve. Any revisions to the product are included in the process or as a task waiting its turn on the WIP list.
Iteration, Cadence, and Scheduling
Time is treated differently by Scrum and Kanban. Analogous to the assembly line, Kanban does not have discrete milestones. Instead, the continuous flow of work is monitored with the use of the Kanban board. Visually, the board shows the status of the tasks and sometimes the members. Iteration is done as a matter of course. Revisions can be done at any time. In the same manner, a task can also be stopped at any time.
Scrum has a strict adherence to timeboxing. Iterations are called sprints and during a sprint, the only work done are the sprint backlog. All others will have to wait for succeeding sprints. For Kanban, the iteration can be included at any time in the process because the process is fluid. Kanban manages the process, and revisions or any changes in the product can be included at any time.
The cadence of Scrum is based on the sprint. This is the primary unit of time measurement for Scrum. The cadence makes use of the regularity of sprints. Typically, sprints are two weeks in length. It could be said that sprints are the unit of time for Scrum.
Kanban enjoys a continuous flow of development. Finished tasks are taken off the WIP list and new tasks are added based on their priority. The only limitation is that the WIP is a thin list which allows a small number of concurrent activities.
In Scrum, scheduling is done during the Sprint Planning meeting. During the sprint planning, product backlogs are chosen for the sprint backlog. Only those chosen will be done during the sprint. All the others will have to wait for succeeding sprints. If there are any revisions, these are included in the product backlog, prioritized and then included in succeeding sprints.
In Kanban, software development is a continuous flow. Depending on the state of the WIP, a revision can be included as soon as the WIP has space for a new task. Kanban is able to schedule any new item or revision and place it on the board. Once on the board, it follows the rules of Kanban regarding WIP. Due to the flexible nature of Kanban, the workflow allows for revisions even while the project is in progress.
In Agile, whenever “the Board” is discussed, it usually refers to the Kanban board, rather than the Scrum board. The Kanban board has a wider scope, it is bigger and contains more data. For these reasons, other Agile methodologies have been known to use the Kanban board for some implementations.
There is considerable discussion about the Kanban board, specifically about what it contains. There are boards which contain team members, tasks, metrics, work in progress, status, commitment point, and delivery point. This provides a complete picture of the project at any one time.
There are others who believe that a smaller and less comprehensive board is enough for their purposes. At the minimum, the Kanban board should represent two Kanban goals: to visualize work and to limit WIP. Everything else is in optional.
To use the board, the members put up stickers or notes on the board representing the tasks to be done, or the user stories. These notes move across the board at work or a change is applied to them. If there are five columns, the stickers would move from the first column, and progress across the board, ending up in the “done” column.
The only limitation on the Kanban board is the number of WIP items. If the WIP items exceed the limits, the team members have to scramble and finish the ongoing WIP items. When that is done, the next priority task is placed on the WIP.
In contrast, the Scrum board is a smaller board which is used specifically for a sprint. Also called the “task board” contains the sprint backlog and functions almost like a mini-Kanban board. The scrum team has the flexibility to design the scrum board according to their liking. Typically, it has several columns for “user stories,” “backlogs” or “not started,” “in progress” and “done.” The scrum team defines the term “done” which becomes the project convention. At the end of the sprint, all the sprint backlogs are on the “done” column.
If these are not on the “done” column, these are put back on the product backlog list and put up for consideration for the next sprint. The scrum board is cleared at the end of the sprint, and new sprint backlogs are put up after the sprint planning.
Responsibilities and Roles
Roles are not unique to Scrum. There are only three roles, with a wide leeway for defining the roles. It has a Scrum Master, a product owner, and the team members. Except for team members, these are abstract ideas or roles, and not necessarily job titles.
The Scrum Master is not necessarily the team leader or project manager. The main job of the Scrum Master is to keep the project development a Scrum project. He ensures that the activities adhere to the Scrum framework. As such, the Scrum Master is usually the person with the most experience in Scrum or has been trained as a Scrum Master.
The Product Owner is a part of the team, however, he can also be the customer, the main point of contact for the customer, or the champion for the product or project under development. He knows the most about the product under development, and is in charge of updating the product backlog updated. He is the person who can add to the product backlog. He is also the only person who can order the sprint stopped. He can introduce revisions to the product and place a priority for the backlog items.
The team members are just that, members of the development team. They are committed to the project development.
Kanban does not have prescribed roles. In the traditional manufacturing model, any member of the team has the power to stop production if any errors are found. In the same manner, if errors are found in the item under WIP, any member can point this out and let the team decide what to do about it. Each member is in development, quality assurance, documentation and any other tasks which need to be done.
When to choose Scrum and when to choose Kanban
Scrum and Kanban are solid candidates when choosing an Agile platform. These embody the Agile mindset of an iterative software development model which quickly delivers software and incrementally improves on it over the project lifetime.
There are some instances when Scrum or Kanban is the obvious choice. If it was a long-term software development project with a high probability of evolving during the development time, both Scrum and Kanban would be a good fit. If it was a project with a fixed deadline, Scrum would most probably be a better choice. If it was a project which would require support and continuous upgrading, Kanban would be a better methodology.
Scrum and Kanban are tools to get the job done. There are other considerations when choosing between the two. However, if the project has a definite end, as well as a prior definition of what a “done” deliverable is, then Scrum is a better choice. If the customer has an active participation in the project, as the product champion or driver, Scrum is also a better choice. If the customer requires that revisions and changes be done immediately, Kanban would be better. These are the ideal situations. If there is an emphasis on documentation, or if documentation has to be done prior to development, then Kanban would be better.
The team makeup can also have an impact on the choice of methodology. Scrum teams have to be committed to the project. Two-week sprints can be very demanding and without the commitment, a team member can just fall off like a leaf in autumn. A team of specialists is better off doing Kanban rather than Scrum.
The above examples are only initial estimates. Agile teams can iterate and revise the processes or any other part of the process or methodology. Ultimately, it is up to the team which methodology they would side with in the Kanban vs. Scrum debate.
Ready to increase your work productivity?
#1 rated scrum tool
Monday.com Project Management Tool
You may also be interested by: