Kanban vs Scrum: How Do You Decide Which Methodology Is Best for You?

As a Project Manager at MindK, I’ve been practicing Agile methodologies for the last 7 years. During this time, I’ve tried both Scrum and Kanban as well as our other variations of the Agile methodology. This allows me to understand there is no clear winner in this debate. Both approaches have their uses, the choice is entirely situational. Going for the wrong framework can have serious consequences. Bearing that in mind, it’s important to understand the difference between Kanban and Scrum as well as when to use them. And this is exactly what we’re going to talk about.

Table of contents:

• Scrum: organizing chaos with short-term planning
• Scrum roles
• Scrum development process
• Scrum release methodology
• Key Scrum metrics
• Kanban: extreme flexibility and simple execution
• Kanban development process
• Kanban roles
• Kanban release methodology
• Kanban metrics
• Scrum vs Kanban comparison

Scrum: organizing chaos with short-term planning

Scrum is, perhaps, the most famous of the Agile frameworks. It focuses on small, self-organized teams that work in short iterations called Sprints. The goal is to release working software at a steady cadence and improve the product based on user feedback.

The main difference between Agile and Scrum is that the latter doesn’t divide the team into developers and testers. Scrum also has no dedicated project managers as everyone is expected to code, test, and manage their own work.

Scrum roles

Scrum teams consist of three, well-defined roles that work as complete equals:

Development team – engineers that deliver the working software, and ensure it’s free of bugs and defects. Our teams often include a UI/UX designer and a professional Business Analytic. The latter helps our clients formulate their requirements as not all of them are familiar with the IT industry.

Product owner (PO) – a customer’s representative that aims to maximize the product’s value. POs need to have a deep understanding of the business problems and be able to communicate project objectives to the development team.

Scrum master – a person who protects the team’s time from outside interruptions and inner distractions. They are responsible for guiding the team to perform at their highest level and maintaining Scrum rituals (which I’ll discuss in the next section). Although I have a Scrum Master certificate as a project manager, I’ve seen experienced developers succeed with this role. So it’s not necessary to have a project manager working on your project.

Scrum development process

Scrum teams work in quick iterations. Each iteration starts with a Sprint planning session and ends with a release of working software and a retrospective meeting. All iterations have a similar duration – usually, 2 or 4 weeks.

Sprint planning is one of the most important Scrum rituals. It is a meeting with the development team and client representatives (optional). Its first part usually lasts no more than 1 hour. During this time, the Product Owner would write user stories (pieces of functionality from the user’s point of view) and add them to a prioritized list called a product backlog. The stories that have the biggest value will get the highest priority.

The second part of Sprint planning can happen without a Product Owner to save the client’s time. The team will pull a number of stories they believe they can complete within one iteration. Typically, those features will share a common goal.

They will split the stories into technical sub-tasks and estimate the amount of work needed to complete them (this work is usually represented in story points instead of man-hours). For the next 2 – 4 weeks the team will commit to the items in Sprint backlog and ignore all other stories.

Scrum teams generally don’t make any changes to the project scope during an iteration. Any new requirements that appear during the Sprint must wait for a new iteration.

Daily Scrums is another important ritual. According to the Agile Manifesto, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Time-boxed standup meetings allow the team to review the progress towards the Sprint goals, synchronize activities, and plan work for the next 24 hours. During a Daily Scrum, each team member has to answer three simple questions:

• What did I do yesterday?
• What am I going to do today?
• Are there any blockers that impede my progress?

Regular meetings ensure that clients receive fewer surprises, even during uncertain times.

Sprint Review happens at the end of an iteration. If everything went as planned, the team demonstrates the newly finished functionality to internal stakeholders. This is the perfect opportunity to discuss any issues and opportunities for improvement.

A Sprint Retrospective will often happen right after the Sprint Review. It’s an internal meeting for the development team with a goal to review the work done, discuss challenges, and adjust the work process for the next iterations. If done properly, retrospectives help build better relationships with the client and improve processes with each new iteration.

Scrum release methodology

Scrum teams should prepare a release-ready piece of functionality by the end of a Sprint. The Product Owner then decides whether to release this functionality or wait for a more opportune moment.
On rare occasions, the team doesn’t reach the Sprint goal (which I’ve never seen during my 7 years at MindK). In this case, the team will skip the release and gather for a retrospective. They try their hardest to understand what went wrong during the Sprint and use the lessons learned to better plan the next iteration.

Key Scrum metrics

Velocity is the main metric used by Scrum teams. It represents the number of story points completed within a Sprint. Tracking velocity allows the team to understand how much work they can realistically finish in the next Sprint. If developers have, for example, completed 25 story points within an iteration, they will never commit to a backlog that has 50 points in it.

Scrum use cases

From our experience, Scrum is mostly suited for projects that require a quick product launch with basic functionality (the so-called MVP – Minimum Viable Product). If you don’t have a clear understanding of the final product, this approach allows you to quickly change the direction of development following a change of requirements.

Here’s an example. One of our clients wanted to develop a visually stunning self-assessment app that would help people choose an optimal career path. The client needed to release the product as soon as possible for two reasons:

• Get feedback as soon as possible to understand whether the app satisfied the expectations of different user types.
• Find early partners and potential investors.

Using the Scrum methodology, we’ve made several quick UX/UI prototypes and showed them to key user groups. Their feedback helped us validate the solution even before the start of development.

As a result, we released an MVP that attracted several corporate customers. Revenues from those early users were reinvested in further product development. As the client now has a budget for continuous development, the team can collect requirements from new users and deliver improvements with each new release.

Xelfer, an interactive psych assessment tool, developed by MindK

From a management point of view, Scrum provides a great balance of control and flexibility. Sprint planning takes some time away from the development but ensures that planned features will be 100% accomplished. This allows the team to see the bigger picture while managing day-to-day processes.

On the other hand, Scrum requires you to have at least some of the features prioritized and planned for the first two Sprints. It also needs high involvement from the client’s side. If you don’t have enough time to dedicate to your project, it’s better to choose a Waterfall or hybrid Agile software development model.

Kanban: extreme flexibility and simple execution

Kanban is another popular Agile framework. Its central feature is a Kanban board – a simple to-do list with stickers that represent different tasks or user stories. The board has several columns representing different stages of work.

The board is highly customizable. You can call your columns anything you want as long as this works for your team. For example, we at MindK use To Do, In Progress, Feedback, Ready for QA, Under Testing, Done, Uploaded to Live, and On Hold.

Kanban development process

As the team works on the stories, the stickers move from left to right between the columns. The board is often wide enough for one card and has a limited depth to reduce the amount of work in progress. When the team completes a user story, the Product Owner pulls the next most valuable task from the backlog and places it on the board.

There are no Sprints or Sprint planning, the process is continuous and can introduce changes at any given time. Unlike Scrum, Kanban can be easily applied to existing processes.

A Kanban team accepts change at any point in time. You can simply add another note to your board or remove tasks that no longer matter.

Kanban roles

Unlike in Scrum, there is no specific “Kanban Master”. Each team member bears the same responsibility for the tasks on the Kanban board. While some teams don’t distinguish between different roles, others have the following two functions:

Service Delivery Manager (SDM) – the person who helps the Kanban team manage the flow of work (from left to right on the board). They make sure there are no blockers, talk to people whose work hasn’t been moving for a long time, and help the team observe Kanban practices.

SDMs also help the team implement the strategy of continuous improvement (Kaizen). They challenge other team members, gather data on the work items, dive deep with questions to find the root cause of any issues, and ensure people don’t repeat the same mistakes.

Service Request Manager (SRM) – an analog of Scrum’s Product Owner. They serve as the bridge between the team and stakeholders. Their aim is to uncover true customer needs and help the team resolve them with their product. Another of their function is to analyze risks and implement mitigations.

Kanban release methodology

There are no Sprints in Kanban. The items written on the board are released as soon as they’re ready. If the team completes an item ahead of schedule, they can release it immediately or wait for a better moment.

Key Kanban metrics

Lead time is the metric that measures developer productivity. It is the time from committing to a piece of work to its completion. In other words, it measures how fast a card moves from the leftmost column on the board to the rightmost column.

Cycle time is a similar metric. It represents the time it takes for an item to go from the actual start of work to its finish.

Kanban teams often use a Cumulative Flow Diagram to visualize the number of cards at each stage in the workflow. The idea is to reduce any bottlenecks. Another way Kanban can deal with bottlenecks is by adding Work in Progress limits. So you can, for example, have no more than 5 items in each column.

Example of a Cumulative Flow Diagram. Source: Kanbanize

Kanban use cases

In my experience, Kanban better fits projects in the maintenance phase. At this stage, the team often has to deal with a constant stream of change requests from the client and fix user-reported bugs.

An on-point case here is one projects where we had to develop a SaaS system for reporting environmental pollution and social responsibility efforts. The project was initially delivered using the Scrum methodology. After going live, the client came with lots of change requests that weren’t connected with each other.

Most of these fixes or new features had to be deployed as soon as developed. As it’s very hard to unite such stories with a single goal and organize them into Sprints, we switched to Kanban, a more flexible framework

Now our PO collects feedback from stakeholders and adds new stories to the product backlog. He then prioritizes features according to their value/risk and adds them to the team’s Trello, one task at a time. The team can work on new stories or security updates as they come and make smaller releases several times a week.

CEMASys, a corporate social responsibility SaaS tool developed by MindK [explore the case study]

Kanban also works in situations where Scrum is too inflexible. For example, when the initial requirements are likely to change often.

This happened during one of our projects when we were developing a social networking app for a German startup. At the time we began the first Sprint, the founders were still unsure about the direction of the app.

That’s why we switched to Kanban during the first month of development. This allowed us to start working on the app while collecting requirements and re-prioritizing features. Kanban requires careful management of client expectations and following at least a general direction of development.

Social network data visualization in the Nevaal app, made by MindK. Source: nevaal.com

Scrum vs Kanban comparison

Scrum pros:

• Allows delivering value at the end of each timeboxed Sprint.
• Provides great transparency for the client.
• Gives an objective way to measure team productivity with Daily Scrums.
• Allows accurate predictions of release dates.
• Provides the team with the exact scope of work required in the next 2-4 weeks.
• Has better-defined goals and a clear product vision.
• Controlling the project scope is easier with Sprint planning.
• Limits the team from changing priorities too frequently, preventing chaotic development.

Kanban pros:

• Extremely flexible. Focus on individual tasks allows to quickly alter the development direction.
• Has fewer processes than Scrum: easy task prioritization eliminates idle time.
• Works even for larger teams.
• Suits service-oriented teams.
• Ideal for the maintenance phase (or situations where you have a continuous stream of change requests).
• Isn’t so sensitive to changes in the team composition without the need to plan Sprints based on team velocity.
• Allows working on one task at a time. The team doesn’t have to re-plan activities when the client changes priorities.
• Isn’t so reliant on high involvement from the client.

Takeaway

The whole Kanban vs Scrum debate can be summarized in a few sentences.

Scrum is a more structured approach with defined roles and rituals that guide the development process.

Kanban is a more flexible approach that allows the team to continuously work on new features and adapt to ever-changing requirements.

From my 7 years of experience at MindK, both Scrum and Kanban have proven to be flexible frameworks that can be adapted to your current processes. Our developers prefer to deliver projects using the Scrum methodology, while Kanban is reserved for the UI/UX design phase with unstable requirements and for active maintenance.

So if you need to build a truly Agile product, MindK has vast experience with both frameworks. Just fill the contact form to get a free consultation with our experts.