Kanban vs. Scrum
Let’s face it, this sound like a deathmatch in outer space between hero and villain. In reality, this is a distinction that can make a world of difference to how business owners, managers, developers, and others track the flow of work coming across their desks.
Kanban and Scrum boards are work-management tools that help you organize and complete projects. These boards do so by visualizing status and progress while optimizing workflow. They are powerful instruments for projects requiring creative collaboration, particularly software development, but equally well-suited for individual time management. They promote effective communication and synergy by making dynamic work processes transparent and intelligible to everyone involved.
Though they serve the same general purpose, the two frameworks offer different sets of advantages and disadvantages to users with different goals and interests.
Read on for a deep dive into the defining characteristics and contrasting benefits and drawbacks of each. Armed with this knowledge, you’ll be in a strong position to decide which system is a better fit for your team’s needs.
What They Have in Common
Kanban and Scrum are workflow optimization products that perform the same overall function but with distinct styles, tools, and methodologies. The boards take inspiration from how physical whiteboards can be used to map out a project structure and timeline. Meaning, Kanban and Scrum use sticky notes (or “cards”) to show project status and progress by a cross-functional team of collaborators.
Both platforms use a “pull system” to break a project’s work into discrete activities. They can then be delegated and monitored, but the boards implement the system differently.
One shared strength is the flexibility with which they allow development teams to adapt the model to their own priorities, methods, and goals. Perhaps the greatest shared strength of Kanban and Scrum is that they capitalize on the fact that the human brain processes visual information 60,000 times faster than text.
Kanban tracks workflow and progress continuously while conserving the number of work-in-progress activities. In its simplest form, it consists of a board with vertical titled columns—To Do, In Progress, and Completed. There are instances where more or even fewer columns are used.
Participants on a Kanban board include stakeholders and product owners, such as the project manager, as well as content developers who are executing on the product roadmap. A board’s action items are represented on cards, usually in the form of User Stories. As we will see in greater detail below, the fact that Kanban’s pull system operates via Work in Progress (WIP) limits can be seen as both a weakness and a strength.
Scrum boards track workflow and progress in Sprints, or discrete timeboxed iterations, in order to focus activity but deliver a substantial amount of work. Sprints last for up to 30 days, with 2 weeks being the most commonly used duration.
Within a sprint, cards representing tasks migrate left to right from a backlog—a prioritized list of action items. Cards advance through the “Tasks Not Started” and “Works in Progress” columns to the “Tasks Completed” column. In this way, a Scrum board’s evolution visually marks the team’s day-to-day progress on tasks throughout the project.
Some Key Differences
1. Backlog Operation
A key ingredient in both Scrum and Kanban boards is what’s called the backlog—an organized, prioritized list of pending features and tasks for delivering a complete product. In the case of Scrum, the product is defined by the Product Owner and the work is managed by the Scrum Master.
The Kanban framework does not rely on this rigid division of labor. In a Kanban workspace, project teammates and others, even clients, perform core functions according to their evolving needs and preferences.
Through the board settings, send an invite (via email, for instance) and anyone can participate by adding, moving, and editing cards. Members can also be assigned to specific cards to share ownership of the task and receive notifications about its status. Or they can be flies on the wall and simply observe by using the “subscribe” feature.
In the Scrum universe, shown above, the work to be done in a given interval is limited to the items moved by a team from the Product Backlog to the Sprint Backlog by means of User Stories.
In Kanban, when a task is ready, it is moved into the To Do column by the owner(s). Generally, the column’s topmost card assigned highest priority. A card moves to the In Progress column when work begins, at which point participants can add comments or invite others. The project ends with the placement of all cards into the Completed column.
2. Scope of Work in Progress
One key difference between the two frameworks is that they model and limit workflow differently. This has advantages or disadvantages, depending on a team’s style or preference.
As seen above with the number 5, Scrum boards restrict the work that can be done during a given cycle. This is because they operate in Sprints. A team commits to completing a given amount of work per Sprint. In the example above, the Sprint consists of exactly 5 tasks. Though the total number of tasks per Sprint is limited, it is possible for all tasks to occupy the In Progress column at the same time.
By contrast, since Kanban boards channel work continuously, the number of tasks allowed to be In Progress must be restricted to prevent bottlenecks. As shown above the Kanban board caps the In Progress column at 5 tasks. This feature can be seen as a benefit, in that it limits the amount of work for which any team member is responsible at one time.
Scrum and Kanban boards also differ in term of which participants have ownership of the board during sessions.
Scrum boards are collectively owned by a team of employee participants whose combined skills are needed to complete the Sprint. Kanban boards, however, don’t require ownership by a specific team or individual. As shown above and discussed earlier, they are simply an open space through which workflows on an ongoing basis.
4. Permission to Edit for Product Owner
Although Scrum boards are visible to whomever is invited, product owners cannot edit sessions after the development team commits to a given number of tasks for the Sprint. Permission to make changes is restricted to the collaborators that jointly own the board.
Here again, Kanban boards differ. They can be edited by product owners.
5. Updating Items Mid-Iteration
During Scrum sessions, members of the scrum team cannot add tasks to those already agreed upon during the pre-iteration collaborative planning session.
Meanwhile, because Kanban boards are open, with work flowing continuously through them, they can be updated with additional tasks at any time by anyone with permission to do so. It is important to note, workflow is limited within the In Progress column. Tickets migrate left to right from column to column, life from In Progress to Completed. When a ticket advances to the next column, the resulting empty column pulls a ticket from the previous column or the backlog to take its place.
Kanban Pros and Cons
The flexibility and open-endedness of the Kanban framework—continuous development and content delivery—is its chief strength. This board is an excellent fit for teams engaged in fluid ongoing work. This means they are working on multiple products, with no single, generally shared release date. It also works well for team efforts organized around evolution or maintenance.
However, without strict In Progress limits imposed by managers or owners, Kanban’s open model can become a liability, with WIP bottlenecks and over-specialization cropping up and undermining productivity.
As Kanban apps go, Trello is known for its flexibility and ease of integration with other tools. Cards can be richly fleshed out or just decorated for fun with stickers. Other tools, like MeisterTask and Leankit are also Kanban apps that organize tasks and guide productivity.
Scrum Pros and Cons
Scrum’s chief advantage is its ability to crank out a fixed value at regular intervals. But less flexibility per iteration is the price your team will pay for a greater measure of predictability.
Whether or not your team will benefit from Scrum’s rigidity also depends on how many irons it has in the fire at once. Scrum works well for teams whose developers can reliably commit to delivering an amount of work with a given value at the end of a pre-designated period. Indeed, one virtue of the Sprint method is its way of incentivizing productivity by focusing effort around a deadline.
But teams whose members cannot reliably make such commitments, who have competing commitments elsewhere, or who bridle at the strict division of roles into Product Owner, Scrum Master, and Development Team, may find Scrum’s format an unwelcome straightjacket. Some common Scrum tools include VersionOne and Axosoft. They are both designed with collaboration and progress tracking in mind
It is difficult to compare Kanban and Scrum in one fell swoop. It would be artificial and simplistic to simply rank one above another. Both offer the benefits of the agile approach to project management and development. But because they implement it so differently, your team’s particular needs and abilities will be the decisive factor in which flag—Kanban or Scrum—is the right one for you to fly.