Kanban vs Scrum: Definitions, Framework & Roles

Kanban Vs Scrum

Agile, Lean, Scrum, Kanban: All these terms describe very similar project management approaches, often used synonymously,

Scrum ceremonies are called agile ceremonies, Kanban boards are used for Scrum – getting a deep understanding of methodological terms can be difficult at first.

This is why in this article Digital Leadership will guide you through Kanban vs Scrum techniques, their roles outside of software development, the agile process and its importance for project managers, and how to choose the best technique for the continuous improvement of your company whilst taking customer feedback into account at all times.

Kanban Vs Scrum: Definitions

What is Kanban?

Kanban was originally developed by Taiichi Ohno, an industrial engineer at Toyota, with the goal of creating a more efficient production process, in 2010 the Kanban method was applied to software development by David J. Anderson in his book Kanban: Evolutionary Change Management for IT Companies.

Kanban uses an assembly line approach: individual tasks are displayed on Kanban boards – a blackboard-like view with columns, the tasks are then moved to different phases until they are completed. Both Kanban and Scrum have a backlog of prioritized project tasks – but instead of scheduling work in sprints, kanban teams select the highest priority task in the backlog.

Kanban Board

The main feature of the Kanban method is the Kanban board. Similar to the manufacturing process, where products are assembled from individual parts on an assembly line, Kanban tasks pass through a series of columns until they are fully completed.

One example of the workflow using kanban boards:

Each task in your backlog requires development on the back-end, then development on the front-end, plus testing, and finally the release.

Your Kanban board depicts all those tasks that are then moved from one column to the next until all steps are completed.

Work In Progress Limit

Another important feature of Kanban is the work-in-progress (WIP) limit. For example, your back-end kanban team is working much faster than your front-end team. As a result, your front-end team would end up with numerous open tasks while in the back-end the entire team will have nothing to do.

WIP limits restrict the number of tasks that can be in a column at one time. When a team’s WIP limit is reached, it’s a signal that the team may be overwhelmed with work.

In such cases, other members of the team could help reduce the number of outstanding tasks. However, a reached WIP limit is usually a sign that the work distribution in the team is unbalanced.

To return to our example scenario: Fewer backend developers and more frontend developers could provide one possible solution to a cross-functional team.

Although Kanban lacks the Scrum-specific retrospective ceremonies, continuous improvement is one of the basic principles.

Teams need to gradually look for ways to improve workflow, remove blockages, and streamline their processes all through the use of kanban boards.

What is Scrum?

Scrum is an agile methodology used to manage and organize tasks into smaller and achievable tasks that can be accomplished within a short time (usually 2-4 weeks long).
To plan and execute this process, scrum relies on three specific roles:

• The Product Owner
• Scrum Master
• Team Members

Agile project management advocates for a collaborative, iterative approach to software development – Scrum is a methodology that is commonly used to put the agile philosophy into practice.

The Scrum approach provides frameworks that project sponsors and software developers can use to collaborate while following agile principles. It was developed by Ken Schwaber and Jeff Sutherland, two members of the Agile Alliance.

Scrum tools help teams implement an agile approach while ensuring that all team members work at a steady pace. A scrum board can help focus on whether the outcome is consistent with what project sponsors want, and that the scrum team improves over the course of a project.

Scrum team Roles:

There are three main roles in a Scrum team, which Digital Leadership will be outlining below:

1- Product Owner

The product owner is a representative of all project stakeholders who is available throughout the development process to answer questions, review completed tasks and prioritize requirements.

Including the product owner in the development process helps the team adhere to the agile approach’s requirement for effective collaboration.

2- Scrum Master

The Scrum Master leads the development team, ensures that everyone can focus on their work, and conducts Scrum meetings.

Similar to a project manager, scrum masters act as the conductors of the scrum teams and ensure that the entire workflow runs smoothly and that the Scrum processes and rules are adhered to.

3- Development Team

A development team is a group of three to nine developers who are responsible for all tasks defined and prioritized by the product owner. They work with a prioritized product backlog (list of all project requirements), which consists of user stories.

User stories do not explain what needs to be done but describe the requirements for the product from a user’s point of view.

User stories always follow a specific format: [who], wants [what], so [why] is it important?

Work during the development process is completed in an iteration known as a sprint – a period of one week to one month during which the scrum team focuses on a specific, planned set of tasks.

These tasks are outlined in sprint planning, where teams identify and plan tasks for user stories that they believe can be completed successfully during the sprint.

During the sprint, Scrum teams have a daily Scrum meeting where each team member answers the following three questions:

1. What did you work on yesterday?
2. What will you work on today?
3. Are there any issues that are preventing you from completing your tasks smoothly?

At the end of each sprint, the team conducts two meetings. The first is the sprint review, where the team presents all tasks completed during the sprint to the product owner for approval.

The second meeting is the sprint retrospective, where the scrum teams analyze the strategic planning process with the aim of improving future sprints.

The following three questions are answered by each team member for this purpose:

1. What went well in this sprint?
2. What could have gone better?
3. What should we do differently in the next sprint?

Kanban Vs Scrum: Framework

Kanban Vs Scrum: Roles

Kanban Vs Scrum: Meetings

Framework	Scrum	Kanban
Timebox	Daily startup meeting	No guidelines
Exchange	Team Retrospective	No guidelines
Steering (Customer & Stakeholder)	Review Meeting after every sprint	No guidelines
Team Forecast	Before every sprint	No guidelines but regular meetings are required

Kanban Vs Scrum: Artifacts

Framework	Scrum	Kanban
List of requirements	Product Backlog	Backlog
Supply cycle	Sprint	Depends on the turnaround time
Board	Sprint Backlog, Scrum board is optional	Kanban board (Permanent: will only be deleted once the project is over)
Delivery	Potentially shippable product increment	Processed tickets
Metrics	Velocity	Lead time, Cycle time, WIP

What does agility mean?

Compared to Scrum and Kanban, agile frameworks are a philosophy rather than a process management methodology.

The term agile was first used in 2001 by The Agile Alliance, a group of 17 software developers, within two days, the developers wrote the Agile Manifesto, a collection of principles designed to promote steady progress as well as collaboration on process documentation and contract negotiations.

Before the Agile Manifesto was published, most software development projects were based on the so-called waterfall principle, a method in which all requirements for projects are defined before development begins.

In this process, teams of developers commit to completing a certain number of tasks in a certain amount of time, not taking into account sponsors feedback and changing priorities throughout, However, this has led to several problems:

If a problem arises during the development process, it is difficult to solve because the whole team has committed to a specific scope of work in advance.

Since the project requirements are written down in advance, the development team members receive very little input from project sponsors throughout the project process, because the development team works in a silo, project sponsors often don’t see a deliverable until the development process is complete. This can result in project sponsors not being satisfied with the final product.

In response to these problems, The Agile Alliance introduced a new, better development approach in which teams collaborate with project sponsors throughout the development process, gathering requirements and building code using an iterative approach, this leads to a continuous flow of work with feedback coming in throughout. Business value is increased through establishing great frequent communication with sponsors.

Agile methodology allows developers to address any issues that arise during the development process and gives project sponsors an overview of the entire project to bring in any concerns before it’s too late.

Scrum and Kanban outside of Software Development

• Update elements such as navigation menus, buttons, and CTAs.
• Update images used in individual blog posts and landing pages
• Update layouts of all landing pages
• Update your company’s style guide to reflect the new guidelines

Because of the tight timeframe and the design team’s collaboration with other teams such as development, sales, product, and marketing, Scrum might be the optimal solution for managing the project.

For most large and complex projects – regardless of the scope of work – the clear structure of Scrum tools is often beneficial. For workflows that require the input or attention of multiple people, the Kanban teams are suitable.

Kanban vs Scrum for Project management: What works best for you?

There are now a large number of tools available for both Kanban and Scrum methodologies, both with widely varying priorities and progress limits.

Some of these have been developed specifically for Scrum, and accordingly offer many functions for Scrum-specific ceremonies such as sprint planning and release planning, and use Scrum terminologies such as user stories and sprints.

While Scrum-specific tools may work well if your team is working exclusively with the Scrum methodology, they can quickly become less effective and quite a bit more difficult if you are planning on using both methods at the same time.

Kanban tools offer more flexibility for teams that want to work with both methods – depending on the individual task requirements.

Of course, Kanban tools are designed for the Kanban method and accordingly well suited for it. But they are just as well suited for a Scrum approach: many teams use a Kanban board for Scrum – a practice also known as ScrumBan.

A Kanban board can start with the Product Backlog column, where all open user stories are listed. Product owners work in this column, creating user stories needed for the project and prioritizing them by arranging tiles in order of priority, for sprint planning, the development team then pulls all user stories into the Sprint Plan column to create a flow for the upcoming sprint. If needed, estimates can also be added and checklists can be used to break down the user stories into individual tasks.

When the development team is working on a user story, team members can move the card to the In Progress column, in addition, the Blocked column can be added to include any User Stories that cannot be completed due to a blocker (which must be removed by the Scrum Master).

Finally, you can add the Completed or Approved column for all User Stories that need to be presented to the Product Owner for approval. Once the User Stories have been approved, each card can be moved to the Done column for the Sprint in which the User Story was completed.

Kanban tools are flexible and easily understood by all interested parties outside the team. Project managers, project sponsors, and team managers can view the board at any time to get a quick overall view of the project’s progress, having an overview of the entire project is also beneficial to teams, as there is much less need for project status meetings and it gives team members the opportunity to review and track progress accordingly.

Build Agile Teams and Processes

At its core, the agile method is about continuous improvement. The Agile Alliance focused on collaboration, flexibility, and incremental performance improvement. But those may not be the improvements your team needs – and that’s completely fine.

Sometimes you will hear people say: “If you’re doing X, you’re not agile.” But agility itself is not a rule-based system, it’s a system of certain principles.

Those principles can be applied by any team in the way that works for them – as long as the project plan, which is continuous improvement, remains the main focus.

Therefore, when researching different agile methods, we would advise you to focus less on the theory and more on solving the problems. Ask yourself: what is complicating the teamwork and delaying the progress? And what approach can we use to solve this and create a smoother working process?

In the end, the definitions and processes are just descriptions. As the agile manifesto states, working software – or the end result – is much more important than how you get there.

Conclusion

To conclude this article, Digital Leadership will give you some hands-on tasks to reflect on in order to find the right method for your team.

How much structure does your team need? Scrum relies on detailed, clearly defined rules and processes. Compared to Scrum, Kanban is a lot more flexible.

Are you dependent on other teams/projects? Scrum’s detailed planning processes are efficient if your work depends mostly on individuals and teams outside of your Scrum team. The Kanban workflow is better when all your work can be done by your own team.

Are your tasks dependent on other tasks? Scrum boards and scheduling works smoothly if some tasks in your backlog are completed before others are processed. Kanban relies on each task being completed in isolation from others.

Ultimately, neither method is inherently better than the other. The right choice for your team depends on your company structure, your team preferences, and the specifics of your work and project goals.