Scrum vs. Kanban

By constantly checking and readjusting („Inspect & Adapt“) and implementing an open feedback culture, potential errors are quickly corrected and changes are reacted to. In this way, cost risks are reduced and the development team can regularly adapt to new requirements.

What is a Sprint? Those who decide to work according to Scrum work in so-called Sprints. These are iterations that usually last two to four weeks. The entire project is therefore divided into smaller sub-goals. In this way, measures can be taken based on the experiences of the current Sprint and a quick adaptation to change (for example customer requirements) becomes possible.

The individual development processes of the project are visualized on a Scrum Board to create transparency between the individual team members. But what needs to be considered when working according to Scrum?

The three Scrum accountabilities

The Product Owner

The Product Owner (PO) is accountable for managing and prioritizing the Product Backlog. The Product Owner is therefore responsible for the success of the entire product and ensures that the customer value is maximized.

The Team

The entire team is responsible for implementing the tasks defined in the Sprint Backlog and presents the finished Product Increment at the end of the Sprint. Each team member is responsible for the development process of the respective task and makes the decisions that fall within this scope.

The Scrum Master

The Scrum Master supports the team by ensuring that each team member and other stakeholders in the organization understand the principles and values of Scrum and implement them correctly. In addition, the Scrum Master organizes the various Scrum Events and protects the team from unauthorized intervention during the Sprint.Since Scrum is used for complex and unpredictable project plans, there are some rules and regulations to be observed. A distinction is made here between three artifacts and regular Scrum Events.

The three artifacts of Scrum

Product Backlog

All requirements that the stakeholders place on a product are recorded in the Product Backlog after coordination with the Product Owner and are managed there. The Product Owner is responsible for prioritizing the individual tasks. These are often formulated in User Stories in order to describe the functionalities of a product from the user’s point of view and to create a common understanding. Learn more about User Stories and User Story Mapping here.

Sprint Backlog

The Sprint Backlog contains selected elements of the Product Backlog, which need to be processed in the next Sprint. These are defined during Sprint Planning by the development team together with the Product Owner according to the prioritized Product Backlog. This creates transparency regarding which User Stories need to be processed during the Sprint in order to achieve the Sprint Goal.

Product Increment

The Increment is the result of each Sprint. The goal is to develop a potentially deliverable Product Increment that creates value for the user. The acceptance criteria defined in the User Stories should be met, so that the Increment is ready according to the „Definition of Done“. In the Definition of Done, the development team and the Product Owner identify properties that must be met for a Story to be considered complete. But which Scrum Events can be distinguished?

The three scrum events

Sprint Planning

At the beginning of each Sprint, the team conducts a planning event called Sprint Planning. The tasks prioritized by the Product Owner are estimated relative to each other depending on their complexity. It is important to estimate on a realistic basis, as no more changes should be made during the Sprint. The tasks to be completed (Stories) are distributed according to the Pull-Principle. The individual team members take on the prioritized tasks by pulling the Stories from the Backlog into the Sprint and committing to them for the upcoming Sprint Period. This avoids overloading the team, as only the number of tasks that can realistically be accomplished gets pulled into the Sprint. All other tasks that are not processed in the Sprint are recorded in the Backlog and taken up in the subsequent Sprints.

Daily Scrum

A 15-minute meeting is held daily with the entire team. The purpose of this meeting is to discuss the status quo and any obstacles or problems that may jeopardize the achievement of the Sprint Goal.

Sprint Review

During the Sprint Review, the finished Product Increment is presented to the Product Owner and, if possible, to other stakeholders. Each team member presents the results of his or her work during the Sprint. Ideally, all Stories should have the status „Done“ at this point.

Sprint Retrospektive

At the Sprint Retrospective, the team reflects on which aspects of the Sprint were positive and which were negative. This event is moderated by the Scrum Master with the goal of collecting ideas and suggestions for optimization and aligning all team members on a common understanding. The Scrum Team agrees to implement two or three of these ideas directly in the next Sprint. But how does one proceed when working according to Kanban?

Agile method: Kanban

Kanban is an agile method used to visualize work processes. The entire workflow of a project is mapped by writing each task to be completed on a card and visualizing it on a Kanban Board. The corresponding tasks are typically pulled to the „To Do“, „In Progress“, „In Validation“ and „Done“ columns depending on their execution status. In this way, team members can get an overview of individual work steps and the entire development process at any time. According to the Kanban method, one task after another is processed and pushed into „Done“ until the project is completed. It is important to note that the number of tasks in each stage of the Kanban Board is limited („Work in Progress“ limit). This serves efficiency and clarity of the project. What are the similarities and differences between Scrum and Kanban?

The similarities of Scrum and Kanban

Both agile methods work according to the Pull-Principle, which ensures fast delivery of results and avoids overloading. In Scrum, this is used within the Sprint Planning. In Kanban the principle is applied continuously. In addition, the methods are characterized by a very similar goal orientation, which focuses on high transparency, flexibility and maximizing the customer value.

The differences between Scrum and Kanban

SCRUM	KANBAN
Planning in iterations	Continuous development process
Requires teamwork	Can be used for individual work
Scrum Boards are renewed for each Sprint and are always structured in the same way	Kanban Boards are used continuously and can be individually structured
Limitation of work through Sprints	Priorities and tasks can be changed and adjusted at any time
More complex due to rules & regulations (meetings, accountabilities, etc.)	More flexible due to optionality of meetings and greater freedom of design
More time consuming due to planning meetings and various events	Time saving (as the whole development process is mapped, less coordination is needed)
Cross functional teams with specific accountabilities	Teams can be specialized, no accountabilities requirements

Conclusion: Scrum or Kanban – which agile method is suitable for what?

Scrum and Kanban are not mutually exclusive methods – they can also be combined. For example, Kanban Boards can also be used in a development process with Scrum. Kanban is strongly focused on visualization, but Scrum is more extensive compared to Kanban and requires teamwork. Scrum is particularly well suited when an incremental approach is possible and large projects can be broken down into individual components. Accordingly, the more complex the project, the more sensible it is to work with Scrum. By dividing the project into Sprints, the process becomes leaner, easier and clearer. Kanban, on the other hand, can also be used for small projects, such as the organization of an event. This agile method is particularly recommended when a quick response to new tasks is required. Kanban is used, for example, in production processes as well as testing, troubleshooting or maintenance tasks. Lead times can be minimized and the process can be continuously improved. Which agile method is ultimately the most suitable however, depends heavily on the project. It is therefore worthwhile to take a closer look at the structures and the setup of the project and, if necessary, to carry out a test phase of the two agile methods Scrum and Kanban.

Contact

If you have any questions about Scrum and Kanban, want to establish the agile methods in your work process or want to perform an agile transformation, feel free to contact us!