Scrum vs Kanban in software development projects.

Scrum – methodology, method or framework?

The answer to this question may turn out to be extremely hard to find, especially if we work in an international environment and try to translate given words into our native languages from English. This means that the translated words may turn out to be vague, and some may even be impossible to translate.

However, if we decide that the Scrum Guide should guide us during our agile adventure in software development, then the answer to the question of whether Scrum is a methodology, method or framework will turn out to be very simple. The words “methodology” and “method” do not appear even once, whereas “framework” in relation to the Scrum concept appears 9 times in the text!

Therefore, we can say, without digging into complicated and ambiguous definitions, that “framework” is the best term for Scrum.

Scrum vs Agile

The terms “Scrum” and “Agile” are often used to represent the same approach / concept, but this should not be the case. Agile includes a group of various agile approaches (frameworks), e.g. SAFe, Scrum, LeSS, and Nexus, which can be tailored to the needs of your organization. Agile is a general term for a flexible proactive approach to software development (or any other) projects. It defines the principles and good practices that allow you to react and change the direction of development during the project. This means it’s more advantageous compared to the traditional approach, which basically assumes compliance with the schedule and assumed scope and cost.

Scrum, in turn, defines only one of the many available agile methodologies and agile approaches to project management.

To sum up, the Scrum framework:

is a flexible and proactive approach to project management.
divides the project into independent, fully cross-functional and self-managed teams.
includes Iterations (Sprints).
is based on 3 pillars: inspection, adaptation, and transparency.
is dedicated to organizations with small teams working on simple products, without complicated dependencies on other teams.
introduces Sprint Planning, Daily Standup, Refinement, Retrospection, Sprint Review and defines the scope of responsibilities for the Product Owner, Scrum Master, and Development Team.

Scrum teams continuously improve their processes and the way they work. The more experienced and well-coordinated the team, the more effective it is. When creating a team, remember that it must consist of members with all the competences needed to define requirements, develop code and test functionalities.

Scrum Guide 2020

The Scrum Guide includes definitions, a description of principles, roles, events, artifacts or best practices in project management. The first version of the document, by the Americans Ken Schwaber and Jeff Sutherland, was released in 2010. The last update appeared in 2020, and the elements that have been changed, added or removed compared to the previous version from 2017 are listed below.

The guide has been shortened and simplified.
- The authors changed the diction, simplified the language so that the content was more understandable, and made the words universal (previously there were mainly references to the IT industry).
The mitigation or removal of prescriptions, removing examples of questions related to the Daily Standup, less explicit attention to the need to introduce ideas, and improvements from the Retrospective in the Sprint Backlog.
Emphasizing the value of the team and all the people responsible for the product being created.
A “Product Goal” was introduced to remind people what the team was built for.
Clarifying liabilities:
- For the Product Backlog, it is the Product Goal.
- For the Sprint Backlog, it is the Sprint Goal.
- For the Increment, it is the Definition of Done (DoD).
The phrase “self-managing team” replaced “self-organizing team” to emphasize that it is the team that independently decides who will perform the work, and when and how it will be done.

So what is Scrum?

The answer to the simplest question – “What is Scrum?” – will not be possible in my opinion without quoting the Scrum Guide. Let this quote become the introduction to our considerations.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat.

Scrum is simple

Scrum is actually based on iteration – the repeatability of Sprints, and increment – the systematic development of previous work effects and verification of whether all previous increments complement each other. As the creators of Scrum, Ken Schwaber and Jeff Sutherland, wrote:

“Scrum is simple”

This means that the Scrum framework may be incomplete and may not answer all the questions that may arise while implementing this approach in your organization. However – and this is intentional – instead of giving ready-made answers to questions and detailed instructions, Scrum creates space to develop relationships and interpersonal interactions.

Scrum Team members

The fundamental element in the Scrum framework is a small team consisting of a Product Owner (PO), a Scrum Master and Developers. The Scrum Team is not divided into sub-teams and there is no hierarchy – each team member is responsible to the same extent for the work that the team performs. At this point it is worth noting that the term “developer” not only describes a programmer, but also people with other functions or other professions whose contribution is necessary to complete the planned work, e.g. UX designer, Business Analyst, etc. All team members are focused on meeting the Sprint Goal and are responsible for achieving the Product Goal.

A Scrum team should not exceed 10 people – from my experience, only then can you achieve the right amount of agility, as well as better communication and synergy. If your team is larger, perhaps you should consider splitting it into two smaller ones – with the same Backlog, Product Goal and PO.

Let me stress that Scrum Teams are self-managed, which means that the team itself decides who will carry out specific work, when and how. It is also the Scrum Team that is responsible for the useful Increment created within the Sprint, which often means the functioning part of the application.

Developers

As per the Scrum Guide: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” It is worth emphasizing once again that developers, contrary to the suggested meaning, are not only programmers, but all those with the necessary skills to fulfill and achieve the Sprint Goal. Developers are responsible, among other things, for creating the Sprint Backlog, Quality Assurance in accordance with the Definition of Ready, as well as mutual support, assistance and responsibility for work.

Product Owner

The Product Owner is responsible for maximizing the business value of the product which the Scrum Team is working on. Importantly, the Product Owner is not and cannot be a supervisor or team manager! He is a member of the Scrum Team with equal rights and responsibilities as set out in the Scrum Guide. The Product Owner’s responsibilities include: prioritizing the Backlog, creating new Backlog items (tasks), as well as explaining and clarifying them.

The term Product Owner refers to one person – not a group of people or team responsible for the abovementioned tasks. Of course, the PO can and should take into account the opinions of stakeholders, business representatives and other people involved in the project, but in the end, it is he who makes the final decisions. It is very important that the Product Owner’s decisions are respected by the entire organization.

Scrum Master

The Scrum Master is a servant leader responsible for the effectiveness and work of the Scrum Team and ensuring that Scrum is used in accordance with the recommendations and guidelines outlined in the Scrum Guide.

The Scrum Master supports the Scrum Team, among other things, by:

teaching them how to be self-managing and self-sufficient.
removing blockers and obstacles that the Scrum Team encounters during their work.
ensuring that Scrum meetings are held, the team knows what they are for – and, if necessary, helping to conduct and facilitate them.

The Scrum Master helps the Product Owner, among other things, by:

finding ways to manage the Backlog effectively.
understanding and introducing an empirical approach to working in an agile environment.
collaborating with stakeholders when needed or asked to do so.

The Scrum Master supports the organization, among other things, by:

spreading knowledge of Scrum and making sure everyone involved understands the idea of iterative and incremental software development
eliminating blockers, barriers and misunderstandings between the Scrum Team and stakeholders
training the organization and its members in the implementation and adaptation of Scrum

Depending on a given project, as well as the maturity of teams and organizations, the work of a Scrum Master may differ in terms of the goals and tasks which he should focus on. The above list, based on examples from the Scrum Guide, obviously does not cover all the tasks and challenges that a Scrum Master may deal with. An agile environment is often characterized by a high level of volatility, so Scrum Masters should be aware of the challenges that await them when cooperating with a Product Owner, team and organization.

Scrum events

Scrum includes several specific events (meetings), the names of which, at first glance, may be enigmatic or even incomprehensible to an outside observer (Sprint, Sprint Planning, Daily Scrum, Sprint Retrospective). The aim of the events is to create a working environment that is sufficiently transparent. Meetings also create an opportunity to inspect and adapt Scrum artifacts. Bear in mind that failure to organize any of the events or carrying them out in a different form than that described in the Scrum Guide is associated with the loss of the possibility of inspection and adaptation as I mentioned before. Meetings should be held in the same place and at the same time to eliminate complications and potential confusion. A well-planned meeting becomes routine and enables everyone involved to prepare properly for it.

Sprint

A Sprint is a Scrum Event that includes all of the other events. The length of the Sprint should be a maximum of 4 weeks, and the next Sprint starts as soon as the previous one is completed. Each Sprint can be considered a separate project, at the end of which the results of work carried out in the previous time period are presented. Cycles, or Sprints, could be imagined as Lego bricks, where each subsequent one contributes to the achievement of the Product Goal, i.e. building a useful internet application.

Sprint Planning

Sprint Planning is the first Sprint meeting, during which an entire Scrum Team determines and decides what will be done in the upcoming Sprint. The Scrum Team is responsible for the course and value of the meeting, but it is possible to invite other people, e.g. stakeholders, to participate as advisers or experts, so as to enable the team to benefit from their knowledge. Sprint Planning should take a maximum of 8 hours (for monthly sprints), but usually takes far less time.

Daily Scrum

A 15-minute meeting for developers held every day in the same place and at the same time. During the Daily Scrum, developers indicate their progress towards the Sprint Goal as well as creating a plan for the upcoming workday. A 15-minute daily meeting facilitates communication in the team, uncovers the problems faced by developers, and gives them the opportunity to raise topics which are important to them. A daily can take many forms as long as the meeting is focused on the Sprint Goal.

Sprint Review

The Sprint Review is a maximum four-hour meeting during which the Scrum Team presents the effects of work carried out during the last Sprint to the stakeholders, and, if necessary, discusses future changes. Contrary to popular opinion, the Sprint Review should not only be a presentation, but rather an opportunity to discuss, evaluate and analyze what has been done and what should be done in the upcoming Sprints. Modifying the Backlog during the Sprint Review is not only allowed, but I would say highly recommended, if it turns out to be necessary during discussions and analyses.

Sprint Retrospective

The Retrospective is the last event in the Sprint, and aims to improve the quality, efficiency and collaboration of the Development Team during the Sprint. The Sprint Retrospective focuses on people, processes and interactions, how they happened, and in particular on improving their correlation and functioning. There is no single proven best way to conduct a successful retrospective. You can use virtual or physical boards divided into sections: what went right, what went wrong, and what can be improved. The most important changes can be added to the Sprint Backlog so that they are not overlooked by the Scrum Team Members.

Definition of Ready and Definition of Done

When working based on an Agile approach, we may come across such terms as “Definition of Ready” and “Definition of Done”. These are very helpful elements and good practices since they clearly define (measure) whether we are ready to include a task in the Sprint Backlog (DoR) and whether the task meets all the assumed and required criteria to consider the task completed (DoD), namely:

DoR (examples):

The task is properly described (has a goal, scope, and completion criteria).
The task is understandable to all team members.
The task is estimated and small enough for the team to complete it during one Sprint – e.g. two weeks).
The task has no open and known dependencies with other tasks.

DoR is most often verified during the Backlog Refinement, where the entire team discusses new tasks as “candidates” for the next Sprint (or Sprints) together. DoR can take the form of a checklist added to each task, or it can be placed on a dedicated platform (e.g. Confluence) as a point of reference for team members.

DoD (examples):

The code was developed based on technological and internal project guidelines.
Unit tests have been created, unit tests are positive.
The code has been verified by a person other than its author (the so-called “code review”).
All acceptance criteria were met.
The functionality has been tested and the test results documented.
The newly developed functionality does not contain open bugs.

The DoD sets out the rules that must be followed in order to complete a specific task. DoD points should be the same for teams working on a single product. Individual teams can add their own points to improve the quality of the software they create.

Product Backlog

This is a set of all tasks that a team or several teams work on simultaneously – a prioritized list telling you what needs to be done to get the product. Each task in the Backlog contains a list of customer requirements (User Stories), technical tasks, defects, etc.

The Product Owner is the person responsible for the Product Backlog – he translates the customer’s requirements into particular tasks and prioritizes them. Other team members also have access to the Product Backlog – they can support and develop tasks as well – but the Product Owner remains the person responsible for decision-making.

The Product Backlog can contain tasks that are already ready to be implemented, as well as those that are general ideas or suggestions for improvement. There is never a final version of the Product Backlog – tasks are created, processed, closed, etc. on an ongoing basis.

The alternatives to Scrum – Kanban

A long, long time ago, employers encouraged people to work in a young and dynamic team, emphasizing such qualities as communicativeness, the willingness to learn quickly, responding to changes and multitasking. Over the years and along with the development of new management methodologies, multitasking, understood as doing many things at the same time, has gained negative connotations. Today it is often associated with time pressure, stress and an overwhelming number of tasks. In 2009 Stanford University wanted to find out if multitaskers are really the top performers. The research results were clear: we pay a high price for carrying out many tasks at the same time. Our concentration and efficiency decreases (according to the American Psychological Association, even by up to 40%), and task overload may even negatively impact IQ or cause permanent changes in the brain. Currently, awareness of the effective time management method is growing. We can observe a shift away from multitasking, but communication, flexibility and continuous development are valued, laying the foundations for agile software development methodologies.

In a world in which we are bombarded with a great deal of information from various sources and communication channels, mindfulness techniques offer a solution. Focusing on here and now is also applicable to IT projects. Kanban (from Japanese: Kàn, Sign; and Bǎn, board, paper) is an agile methodology which, like mindfulness training, helps to control chaos and concentrate on important things. Instead of starting several tasks and switching between different activities, the team first closes one task and then starts working on the next one so that there are as few tasks “in progress” as possible.

Kanban principles and practices

Kanban, as an agile approach, is distinguished by the following principles:

Start with what you are currently doing.
Agree to deliver changes incrementally.
Respect the process, roles and responsibilities.
Encourage leadership at all levels.

As well as good practices:

Visualize.
Limit work in progress.
Manage the flow of work.
Explain the process.
Use feedback loops.
Improve.

The Kanban method, like mindfulness, uses the potential of visualization. You can present all tasks along with their statuses (e.g. planned, in progress, done) and track workflows on the Kanban board. You also gain real-time insight into the tasks of other team members. The idea is simple: Instead of starting one task, moving on to the next one, and figuring out the next one in the meantime, Kanban teams focus on completing open tasks, so as to minimize tasks “in progress”.

Scrum vs Kanban

We want to be agile – which approach we should start with? Both approaches facilitate work and are willingly used by small teams. Kanban and Scrum lead in the same direction, but they use different techniques to achieve the goal. Scrum focuses on delivering a constantly improved product, while Kanban focuses on minimizing work in progress and improving the work itself.

Scrum

An iterative approach which includes a specific time frame (e.g. a Sprint of one / two weeks).
The Scrum Master acts as a facilitator and helps to indicate and remove blockers.
The team reacts to any changes by selecting tasks from the Product Backlog.
Scrum is well described and its principles are defined in the Scrum Guide.

Kanban

It has no fixed timeframe.
It is focused on continuous work, transparency and process improvement.
It does not distinguish scopes of responsibilities (there is neither a Scrum Master nor a Product Owner).
The entire team is responsible for solving any problems that arise. The team reacts to any changes on an ongoing basis.
The Kanban approach aims to eliminate shortages, delays, inventories, queues, inaction, unnecessary actions and movements.

Both approaches motivate team members and aim to improve efficiency. It is worth remembering that the framework should be selected according to the project needs and approved by team members. Scrum or Kanban implemented by force can turn out to be counterproductive. Therefore, it is good to ask the following questions: “What do we want to achieve?”, and “What are the needs of our team?” It is worth taking the time to recognize the needs and learn about the challenges faced by individual team members in their daily work.

When it is worthwhile using Scrum

Scrum works well for project teams no larger than 10 people who are involved in product development or providing services. In Scrum, software (or any other product) is constantly being developed. For this reason, this approach is a good choice for team members who seek ways to improve the quality of a delivered solution, and where the specifications are known and provided by the business (Product Owner). It will also work well in teams that pay attention to communication, since Scrum meetings facilitate this a great deal.

When it is worthwhile using Kanban

It is worth using Kanban in small teams that work on projects characterized by dynamics. Kanban will work well when a team needs a high degree of flexibility. If your projects are experiencing standstills and efficiency drops, Kanban boards will help you detect and remove blockers as well as improving work through the efforts of the entire team.

Kanban goals

Minimizing work in progress and focusing on completing tasks.
Identifying and removing blockers or so-called bottlenecks.
Quickly reacting to changes at any time.
Better insight into the flow of work.

Scrum goals

Providing working functionalities in short periods.
Continuous product development and improvement.
Flexible response to changes within a given Sprint.
Inspection and improvement of processes.

How to measure efficiency? Metrics in Scrum and Kanban

How will we know that using a given approach translates to effectiveness? Is it something that can be measured? in both Kanban and Scrum, metrics can be used, but in the case of Scrum, as the Scrum Guide emphasizes, they are not the essence of Scrum.

Why is it worth verifying metrics and presenting data to the team?

To check which tasks the team has completed and which ones they haven’t.
To see how successful Sprint Planning has been.
To find out more about Team Velocity (this is most often the average number of completed Story Points, that is, units used to estimate complexity), from the last few Sprints.
To make the next Sprint Planning better, more dependable and predictable To see if there are any tendencies within the team (e.g. productivity increases or decreases).

Examples of metrics in Scrum

Verification of whether the Sprint Goal has been achieved.
Burndown Chart – shows the number of tasks added to the Sprint in the context of the time remaining until the end of the Sprint. There are two lines. The “ideal line” shows the perfect variant (the daily number of completed tasks in Story Points), while the second line shows where we actually are. The graph allows you to verify whether you are working as expected, and shows areas in which you have a backlog and there is a small chance of completing Sprint tasks. It may also indicate that you have some buffer.

Velocity Chart – visualizes the amount of work planned vs work completed for completed Sprints. This chart helps to find the optimal number of Story Points for your team as a benchmark in terms of Sprint Planning.

The number of completed Story Points per member.
The number of errors in the Sprint.
The number of tasks added or removed during the Sprint.
The average time needed to complete 1 Story Point.

Examples of Kanban metrics:

Work in Progress – the number of tasks started but not yet completed.
Lead time – the average amount of time from the creation of a request to its completion.
Cycle time – the average amount of time spent working on a task.
Throughput – the number of completed tasks.
Flow Diagram – a cumulative graph that presents changes over time in the context of ticket statuses.

Metrics in Scrum and Kanban may differ depending on the organization of work, but they can be used in a supplementary manner. The collected data should be presented to the team and whether or not the charts reflect the actual state of play should be discussed. In Scrum this would mean discussing situations from the Sprint (or from the last few Sprints) and whether they can be used to implement new ideas and introduce improvements.

Presenting the metrics to the team is not done with the goal of pressuring them to deliver more and faster. The main goal here is to ensure that the team knows when and how to use the metrics, as well as what value can be gleaned from the data. Furthermore, it creates a space for discussion of the above metrics – it is also worth remembering the role of communication in the Agile approach, and therefore it is a good idea to talk regularly with the end customer or perform usability tests. This will allow you to evaluate the quality of the products developed by the team from a different perspective.

PROJECT MANAGEMENT

How to work effectively with Agile nearshore teams? Get to know the benefits of Agile Nearshore Software development Read the text to find out more!

To sum up…

At a time when software development projects are characterized by dynamics (including market needs and the digitalization boom caused by the pandemic), a cross-functional Development Team with tools such as a Scrum board or Kanban board can work more efficiently.

Agile approaches such as Scrum and Kanban focus on continuous improvement: Scrum on improving functionality so that the team can deliver a working item by the end of each Sprint, and Kanban on developing collaboration and continuous improvement. No matter which Agile framework you choose for your project, you can rest assured that product development will benefit in the long run.

Authors:

Łukasz Tudzierz

The Scrum Master at JCommerce. Currently working on a project for a FinTech client. Łukasz believes in empiricism and iteration and teaches Scrum Teams independence and responsibility. Outside of work, he’s a mountaineer and climber, as well as the operator of the Tuudi.net portal.

Sylwester Kułakowski

The Scrum Master at JCommerce. In the IT industry from 2015. He has experience in the area of insurance, banking and public sector projects. Obtained certificates: Professional Scrum Master, Agile PM, Prince2, ITIL i ISTQB. In private life, he is involved in sports activities, such as cycling, football and volleyball.

Cooperation:

Beata Baranowska

Content Marketing Specialist. At JCommerce since 2019. She helps create content that builds and reinforces the brand image. Supports IT experts and B2B sales departments.

Scrum vs Kanban. Which to choose in software development?