Which agile development framework to choose AKA from Scrum to Scrumban

In 2024, over 86% of software development companies use an agile approach for developing their products and services. The method is also quickly expanding into other areas – for example, marketing, healthcare, education, and even construction – where there is a need to efficiently execute different projects. 

 

The agile approach differs from a traditional one in its values, which are listed in the Agile manifesto compiled in 2001. A summary of it would be that the method is based on flexibility, quickly reacting to changes, and collaboration between teams. Implementing the method helps to create different solutions more efficiently, of a better quality, and to ensure that the end results better meets the customer or user needs. 

 

There are various frameworks that use this mindset in the agile world. The most popular ones are Scrum, Kanban, and their hybrid form Scrumban. Each framework has its own approach that is suitable for realising different kinds of projects based on their nature. In this post, we will describe the three most popular frameworks and their properties to help you make the best decision for your project.

 

 

What is Scrum?

Scrum is one of the very first agile frameworks, which is based on the teams’ close cooperation with the users. The first version of the Scrum framework was developed in the 1980s – so even before the agile method was defined. It is currently the most popular agile framework and used by about 66% of companies that implement an agile approach. The main principles of Scrum are cooperation, the project’s iterative progress, and adapting to changes. 

 

Work is done in cycles (sprints) that consist of functionalities that have been divided into smaller tasks and at the end of each cycle, at least one new usable piece of the final solution (increment) is completed. The nature of Scrum is defined in the Scrum guide. Next, we will take a closer look at the nature of Scrum.

 

 

The Scrum framework

Scrum is a clearly defined project management framework that consists of the following parts:

 

• three pillars and five values; 
• three roles; 
• three artifacts; 
• five events. 

 

It should be said that, as with a lot of other popular frameworks, the Scrum framework also does not define how the project tasks should be divided up or evaluated. 

 

To prove a person’s knowledge of the Scrum framework, various accredited institutions also give out appropriate certificates. You can read more about how Trinidad Wiseman’s specialists acquired their Scrum Master certificates from our article “What is a Scrum Master certificate and how can you get one?”. 

 

 

Three pillars and five values

The Scrum framework is based on three pillars: transparency, inspection, and adaptation. These help the Scrum team to constantly be in the same information space, which enables them to efficiently react to changes and improve work processes. 

 

The Scrum guide also defines five values: commitment, focus, openness, respect, and courage. These values emphasise the importance of cooperation and achieving the best possible end result. 

 

Roles

Scrum defines three roles that may be different from “regular roles” that we are used to, such as IT project manager, IT product manager or developer. For example, the IT project manager tasks are divided between the product owner and the Scrum Master in Scrum. The Scrum roles make up the Scrum team, which is the heart of the Scrum framework. 

 

At the same time, the size of a Scrum team is limited within the framework – it must remain below 9 people and ideally, Scrum projects are realised with 7 team members. To successfully employ the framework, the Scrum team must be 100% devoted to one project.

 

• The Product Owner, (PO) represents the user and designates and manages the product backlog. The PO adds user stories, orders items according to their value, makes product-related decisions, knows the end user, and gives input to the developers. The Product owner may delegate their tasks to someone on the development team, for example, an analyst or a UX designer.
• The Scrum Master (SM) knows the Scrum process through and through, teaches it to the team, supports the team and helps the team get past any obstacles that appear during the project. The Scrum Master does not participate directly in project delivery nor does the Scrum Master need to have a technical background.
• The Developers are a cross-functional group responsible for delivering the products or service. In addition to the developers, this group also includes other project-related roles – analysts, UX and UI designers, testers, specialists, and others. They are committed to creating the product and decide among themselves which tasks from the current Sprint each member of the team will be working on.

 

 Artifacts

Scrum artifacts are sources of information that the Scrum team and other interested parties (stakeholders) use on a daily basis when working on the project. It is important to keep the main pieces of information transparent so that all parties involved can be kept up to date on the details, activities and processes that take place during the creation of the product.

 

• The Product Backlog is an ordered list of every functionality, improvement and fix that is needed for the product. Visually, the top of the backlog includes detailed descriptions of the items and the bottom is comprised of high-level ideas.
• The Sprint Backlog is a list of Product Backlog items that have been selected for the current Sprint based on the Sprint Goal. Once the Sprint starts, no new items can be added to the Sprint Backlog nor can existing ones be changed.
• An Increment is a finalised part of the full solution, created during a Sprint, that is potentially ready for delivery.

 

Scrum events

Scrum events (also known as ceremonies) can help the development team remain organised, to focus on the Sprint tasks and the Sprint Goal, and to keep evolving by constantly improving the work processes and providing feedback.

 

• A Sprint is a fixed length development cycle. Usually, a Sprint lasts for 2-4 weeks and its length is decided by the team. Tasks in a Sprint are considered finished once they meet the Definition of Done (DoD).
• Sprint Planning meetings are where decisions are made about what tasks and to what extent need to get done during a new Sprint based on the Sprint Goal. For a one-month Sprint, the maximum allocated time for this event is 8 hours. 
• The Daily Scrum is a short daily meeting for discussing the team’s progress and any obstacles, and for making a plan for the day. This event is limited to 15 minutes a day.
• The Sprint Review is a meeting at the end of a Sprint with the purpose of presenting the results of the current Sprint’s work getting feedback for it. This is usually also when a demo is done to present all the finished work. For a one-month Sprint, the maximum allocated time for this event is 4 hours.
• The Sprint Retrospective is a meeting where the team can analyse its work processes and discuss how to improve them. For a one-month Sprint, the maximum allocated time for this event is 3 hours.

 

It is important to note that Grooming and Product Backlog Refinement sessions are not part of Scrum events. Product Backlog Refinement sessions can be held at any time in any form throughout the Sprint (meetings, quick discussions, phone calls etc.). This is an ongoing process and is not limited to one meeting per Sprint.

 

 

What is Kanban?

The Kanban framework is one option for implementing both the agile method but also, for example, the DevOps method. Kanban originated from Toyota’s production optimisation methods (the lean manufacturing method) and today, thousands of companies who use the agile approach have implemented this method. The purpose of Kanban is to improve workflows and cooperation to increase efficiency and productivity.

 

 

 

Kanban principles and components

At the core of Kanban is a visual board where all of the tasks are displayed in columns on cards with various details on them – name, person responsible for the task, deadline etc. The columns reflect the different statuses of the project task, for example selected for development, in progress, on hold, and done. The cards move across the board according to their current status. 

 

Boards like this are also used by various project management softwares, such as Atlassian Jira. The purpose of this kind of board is to create transparency in the work being done, to help keep track of how the project tasks are progressing, and to identify any bottlenecks and opportunities for improving the workflow. 

 

Every column on a Kanban board is limited to a specific number of cards to limit the amount of functionalities being worked on at a time (Work in Progress, WIP). This is necessary for creating a smooth workflow and for ensuring that the team is not overwhelmed by tasks. 

 

Kanban supports continuous delivery of tasks or releases. As soon as tasks are completed, they are also released. They are considered ready once they meet the Definition of Done AKA everything meets the quality standard. This helps to also avoid the accumulation of incomplete tasks in a workflow. 

 

The Kanban framework emphasises continuous improvement, tracking and optimisation. Teams meet on a regular basis to discuss how they could improve their workflows, use their resources more efficiently, and learn from their experiences. User-centered design is also very important in this framework and helps the teams to focus on the most important tasks that create the most value. 

 

The Kanban framework also utilises the Product Backlog and task ordering. Tasks are selected for development from the backlog by placing them on the Kanban board. The developers then choose which tasks to work on from that list (pull system). 

 

 

Kanban vs Scrum

The Kanban and Scrum frameworks have a lot in common. The processes of both emphasise user-centricity, the constant improvement of teams and their work, and transparency in the project. Both frameworks also place importance on task ordering to create maximum value. 

 

The advantage of Kanban is that it is easy for the development team to adapt to since it uses visual tools and is not limited to different roles, events or time limits. It does not involve complex rules or strict process descriptions. Every team can adapt the framework to the needs of their product/service or team. 

 

Scrum places the emphasis on incremental development done within set timeframes, which helps teams to provide feedback for completed works and processes, and to improve them. It also emphasises the self-organisation of teams. Doing the tasks within set timeframes brings clarity and goal-centricity to the process. 

 

 

Scrum is more suitable for projects where...

• there is a clear goal; 
• development needs to be done quickly and the product needs to be delivered fast; 
• the Scrum team and stakeholders are ready for an intensive development process; 
• the team includes no more than 9 members; 
• the team is able to completely commit to one project only, 100%; 
• the team is able to work closely, in the same room, on a daily basis; 
• the team is already familiar with Scrum or read to quickly learn the complex Scrum framework as they work; 
• the product or service being developed is complex and needs to be broken up into smaller parts; 
• the work priorities are not constantly changed; 
• the focus is on meeting deadlines; 
• there is a need to achieve very good predictability and planning. 

 

Kanban is more suitable for projects where...

• the team size is not limited; 
• the team does not work in the same room on a daily basis; 
• the development team is also working on other projects at the same time; 
• it is not possible to predict the work tasks and they are constantly changing; 
• the work priorities change often; 
• the work is done in a constant flow; 
• there is no need to complete the tasks within set timeframes; 
• there is a constant need to discuss things with different stakeholders and interested parties. 

 

It is also possible to choose between Scrum and Kanban dependent on what phase the project is currently in. During the active development phase, Scrum could be used, and for the maintenance and smaller follow-up developments phase, the team can switch over to Kanban.

 

 

Scrumban – the best combination of the two

In software development, Kanban is often used with Scrum, a hybrid called Scrumban. Implementing the Scrumban framework has become increasingly popular in various organisations.

 

At first, it was created so that teams that were used to Kanban would have an easier time of switching over to Scrum. At this time, this framework does not have an exact definition, so teams are able to create their own principles to follow when working on a project.

 

 

Scrumban principles and components

Scrumban combines the advantages of both approaches, which means that its implementation brings both flexibility and structure to a project – the workflow is managed in a flexible manner, it is visualised on a board, but there are also work cycles (Sprints) and planning events. 

 

Scrumban is suitable for projects where the requirements and priorities are constantly changing, but it is still important to have a regular overview of all the processes, which enables preventing any possible issues. If needed, tasks can be added to a cycle or existing ones changed, and the team does not need to wait for the end of a cycle to take on new tasks. Regular meetings help ensure that there are no shortcomings in the communication. 

 

Work cycles are managed by limiting tasks (WIP). Once the number of “selected for development” tasks falls below a set limit, it is time for a new planning meeting. Work cycles are kept short to be able to adapt to any changes. Ideally, they are 2 weeks long. 

 

Ordering tasks is still important within the Scrumban framework as is their level of detail in the Product Backlog. The pull system is used, meaning that the development team chooses their own tasks to work on from the “selected for development” column.

 

 

Examples of how the different frameworks are used

Scrum may be most suitable in a situation where it is necessary to create a business critical information system based on specific business needs and the Product Owner’s clear vision. 

 

For example, the plan is to release a new product on the market in one year and it is necessary to create a self-service environment that enables the user to create regular and complex order plans. 

 

Or maybe the company wishes to create a new technology or improve an existing one – for example, a drone that needs to be able to fly twice as higher and further than currently and be capable of taking high-quality photos. 

 

At Trinidad Wiseman, we have used the Scrum framework when working on huge information systems and self-service environments. For example, we helped create the self-service environment of the Labour Inspectorate, which is used internally by the Labour Inspectorate to conduct proceedings, and which also includes a client portal and tools meant for employers. 

 

Kanban is suitable for systems where the product vision is still hazy and will become clearer as the work is being done. 

 

For example, there is an existing information system for which a regular continued development cycle is planned. User feedback is collected for a new functionality to be created, requirements are defined based on the wishes expressed, and the application is then developed iteratively. While adding new features to the product is the broader goal and creates a regular rhythm, there is no specific time criticality nor a precisely defined goal. 

 

At Trinidad Wiseman, we have done additional developments for various projects. For example, we created the Digital Traffic Accident Notification System for the Estonian Motor Insurance Bureau. Once the project was completed, it moved on into the additional developments phase. 

 

Sometimes, the framework may need to change based on the development phase. For example, we used the Scrumban approach when creating the Haldusnet information system for Kvatro. Once the active development phase was over, the project switched over to Kanban for the maintenance phase. After a while, new needs for the information system became apparent and, based on their business criticality, the works that needed to be done for those needs to be met were done using Scrumban once again.

 

 

 

Conclusion

Scrum, Kanban, and their hybrid Scrumban are the most popular frameworks based on the agile methodology. These frameworks do not compete with one another and each create a different kind of value. Every team can choose the framework that is most suitable for their goal, the project requirements, the nature of the work, and the team’s habits. It is important to understand the advantages and disadvantages of each framework to be able to make the right decision when choosing a framework to achieve the best possible result when creating a product or service. 

 

This quiz can help you find the most suitable framework for your project.