What is Scrumban?
Table of Contents: Definition – History – Differences and similarities between Scrum and Kanban – Bucket size planning – Variations – Questions from the field – Notes
Smartpedia: Scrumban combines parts of Scrum and Kanban with its own elements to carry out projects in an agile, structured and well-organised manner.
Scrumban – combining and enhancing the best of different approaches
Do you want to work in an agile way but still be able to see the state of development at any time? Do you want to be flexible while also acting in a structured way, and at the same time manage the workload of project or development staff in a meaningful way? Do you want to plan in the long, medium and short term? Then Scrumban could be an interesting approach for you!
Scrumban combines central elements of Scrum, a framework with events, responsibilities and artefacts for the iterative development of complex products and services, and Kanban, a method for visualising work processes that helps to identify bottlenecks and continuously improve workflows. This combination is extended by additional elements.
The history of Scrumban
The development of Scrumban is based on the growing need to combine the advantages of Scrum and Kanban to enable teams to work more flexibly and efficiently. Corey Ladas, a US-American management consultant and former Microsoft development manager, coined the term in a 2008 document of the same name and published the book ‘Scrumban: Essays on Kanban Systems for Lean Software Development’ in 2009, in which he comprehensively described the approach [1].
Scrum and Kanban are two of the best-known agile approaches, each with their own strengths. Scrum offers a fixed framework that uses so-called sprints, defined responsibilities (scrum master, product owner, developer) and a clear structure for organising tasks. It is particularly effective for projects that require regular iterations and feedback loops.
Kanban is an approach based on visualising workflows. It allows teams to work on tasks in a continuous flow and uses work-in-progress (WIP) limits to maximise productivity and avoid bottlenecks. Kanban is particularly suitable for teams that need to react dynamically to changes and do not require fixed cycles.
The development of Scrumban was influenced by the concept of Feature Crews at Microsoft. Feature Crews are individually assembled, cross-functional teams responsible for developing specific features. Within these crews, the Kanban board was frequently used to visualise the work steps and optimise the distribution of tasks.
Corey Ladas observed how the feature crews worked at Microsoft and saw the potential to combine the flexibility of Kanban with the structured planning of Scrum. And he developed Scrumban as an approach to make it easier for teams already using Scrum to switch to Kanban. Many teams were satisfied with the fixed structures of Scrum, but needed more flexibility in their workflows, especially when taking on continuous tasks such as maintenance or support. What was intended as a transition quickly developed into an approach in its own right. Many teams found that Scrumban could also be used as a permanent solution.
Differences and similarities between Scrum and Kanban
To understand the differences and similarities between Scrum and Kanban, it is worth taking a look at the central elements of the approaches, at the collaboration between those involved and at values.
Let’s start with Scrum:
Scrum is a framework for the step-by-step planning and realisation of products and services. It helps companies when developments are too complex for precise planning at the beginning of a project, when requirements or priorities change, when customers need quick added value or when risks need to be minimised. It defines an incremental, iterative approach and is based on empiricism (knowledge arises from experience and decisions are made on the basis of observations) and lean thinking (waste is avoided and the focus is on the essentials).
The framework and its ‘rules’ are defined in the Scrum Guide. This lists
- five events (sprint, sprint planning, daily scrum, sprint review and sprint retrospective),
- three accountabilities (scrum master, product owner and developer) and
- three artefacts (product backlog, sprint backlog and increment).
The heart of the framework is the so-called sprint. It encompasses all other events. It is an iteration of a consistent duration with similar actions. For the approach to work, organisations must not only learn to apply the rules of the framework, but also develop an open attitude to bring the values (commitment, courage, openness, focus and respect) to life.
And what about Kanban?
Kanban is a method of work and process management that was developed in the 1940s in the Japanese automotive industry to optimise the flow of materials in production processes. Since the 2000s, Kanban has also been used in knowledge work and is considered a method in agile project management and in software and product development.
It is based on four basic principles that ensure that processes can be improved efficiently and continuously:
- Start with what you are doing now
- Pursue incremental, evolutionary changes
- Respect existing processes, roles and responsibilities
- Encourage people at all levels to take the lead
These principles are universally applicable, whether in production, software development or other areas of knowledge work. In addition to the four principles, Kanban also has six practices:
- visualise your work
- limit parallel work (WIP limit)
- manage the workflow
- formulate explicit process rules
- implement feedback loops
- Continuously and jointly improve the process
In addition to the principles and practices, Kanban is based on nine values:
- Transparency
- Balance
- Collaboration
- Customer focus
- Workflow
- Leadership
- Understanding
- Agreement
- Respect
These values form the backbone of the Kanban method and help teams not only to organise their work but also to develop a culture of continuous improvement, learning and collaboration.
On closer inspection, it can be seen that many aspects of the two approaches are very similar. Kanban speaks of customer focus, while Scrum defines a sprint goal that determines why the sprint is important to stakeholders. Kanban uses feedback loops and Scrum encourages sprint reviews and retrospectives. Kanban speaks of leadership and agreement, while Scrum speaks of courage and commitment.
And what are the differences between Scrum and Kanban?
Scrum works with defined iterations of consistent duration, the so-called sprints, which usually last from 1 to 4 weeks. At the end of each sprint, a functional product increment must be available. It defines three specific accountabilities (Scrum Master, Product Owner and Developer) with corresponding activities, uses five events (sprint, sprint planning, daily scrum, sprint review and sprint retrospective) and declares three artefacts (product backlog, sprint backlog and increment).
In contrast, Kanban works without fixed iterations. Tasks are continuously pushed through the workflow as soon as capacity becomes available. There are no fixed roles and the approach is flexible in terms of meetings and events, although regular reviews, feedback loops and workflow adjustments are practised. In addition, Kanban uses WIP limits to restrict the number of simultaneously processed tasks and to focus on completing the tasks.
Scrum addresses the delivery of a defined scope within a sprint. It emphasises the incremental growth of the product with the aim of having a potentially deliverable product increment at the end of each sprint. The scope is jointly estimated and agreed before each sprint. Changes during a sprint are possible but are ideally avoided. New tasks are usually prioritised in the sprint planning. Tools such as task boards, burn-down or burn-up charts are frequently used in practice but are not mentioned in the Scrum Guide.
Kanban, on the other hand, prioritises continuous workflow and optimising the overall process. The aim is to shorten throughput times and identify bottlenecks. The goal is to achieve a consistent, stable workflow in which tasks are completed as quickly and efficiently as possible. Changes can be made at any time because there are no fixed iterations. Tasks are prioritised dynamically, often in real time, based on current demand and availability. The workflow is visualised using the Kanban board.
Conclusion: There are many similarities and commonalities between the two approaches. Scrum defines elements that Kanban does not explicitly mention. And Kanban offers aspects that can meaningfully complement the practical application of Scrum through the visualisation of the workflow and the use of WIP limits.
Bucket size planning in Scrumban
Bucket size planning is a special method in Scrumban that is used to divide tasks into different ‘buckets’ based on their time horizon. This classification helps teams to set priorities while enabling long-term planning that can flexibly respond to changes. The buckets represent different planning phases and range from long-term strategic goals to short-term detailed tasks.
Typically, the system includes three buckets:
- The long-term bucket (often the 1-year bucket) is used for strategic goals, such as entering new markets or launching a new product. Such tasks are not very detailed and only provide a rough overview of future activities.
- Once the company decides to move forward with a plan, aspects are fleshed out and end up in the second bucket (often the 6-month bucket). In this phase, the main requirements of the plan emerge and the tasks are worked out in more detail. This phase serves as preparation for the actual implementation.
- The third bucket (often the 3-month bucket) is where tasks that can be broken into clear, actionable pieces that can be worked on immediately end up. As soon as the team is ready to take on new tasks, it ‘pulls’ the work from this bucket and starts implementing it. This dynamic, demand-driven approach ensures that work flows continuously without relying on fixed planning meetings.
Bucket-size planning enables teams to break down strategic long-term goals into smaller, short-term tasks that can then be worked on according to capacity and priority. This allows the team to remain flexible and responsive while keeping long-term planning in view and implementing it step by step.
What are some practical variations of Scrumban?
Scrumban is an extremely flexible approach that can take on different forms depending on the team and project. Teams can decide which elements of Scrum and Kanban they want to keep or adapt. Here are some of the variations of Scrumban in practice:
Scrum with Kanban board and WIP limits
In this variant, the team uses the full Scrum approach and additionally the Kanban board to visualise the work and WIP limits to restrict simultaneous tasks. Depending on the specific setup, the Kanban board can replace the classic sprint backlog or serve as a display of the workflow of the activities that were planned in the sprint backlog. Either way, the overview in the current sprint improves; unsurprisingly, this is likely to be the most common variant in practice.
Scrumban without accountabilitys
In this variant, the team dispenses with the formal accountabilitys such as Scrum Master and Product Owner. The team works in a self-organised manner in that it controls the workflow using a pull system and WIP limit, while the planning and role structure of Scrum is reduced or omitted altogether. This variant is suitable, for example, for teams that operate with classic roles.
Scrumban without iterations
This variant dispenses with the fixed sprints, allowing the team to work in a continuous flow without the cycle of fixed iterations. The Kanban board is the central element, while tasks are flexibly pushed through the workflow. Teams work dynamically and react flexibly to new requirements or changes without being tied to fixed time frames. This variant is well suited to environments with rapidly changing requirements or support and maintenance teams where continuous task processing is important.
Scrumban with bucket-size planning
This variant uses the bucket size approach, in which tasks are categorised into long-term, medium-term and short-term buckets. Teams pull their tasks from the short-term buckets. This variant is particularly suitable for larger projects with multiple phases or for strategic plans that are gradually translated into detailed tasks.
Conclusion:
Scrumban offers various possibilities for combining and adapting Scrum and Kanban. Teams can flexibly design the framework by either retaining the structured elements of Scrum and adding Kanban elements or by orienting themselves more towards Kanban in order to maximise agility and flexibility. Whether you practice Scrumban with or without sprints, roles or buckets, it can be individually adapted to the requirements and working methods of a team.
Questions from the field
Here are some questions and answers from the field:
What are the advantages of Scrumban?
Scrumban combines the best elements of Scrum and Kanban, providing a flexible, adaptable method suitable for a range of different work environments. Some of its key benefits include:
- It is particularly flexible because teams can decide which elements of Scrum and Kanban they want to use. They can use sprints but don’t have to, and can work either in a highly structured or loosely organised way, depending on the project requirements. This makes Scrumban easier to adapt to changing requirements or new priorities.
- By using work-in-progress (WIP) limits and a pull system, the focus is placed on completing tasks. This helps to reduce multitasking and increase efficiency by allowing the team to focus on a limited number of tasks at a time. Bottlenecks quickly become visible and can be addressed directly, resulting in greater control over the work process.
- It allows teams to make continuous adjustments and improvements because there are no fixed sprints or closed periods. Teams can regularly optimise their work process by responding to current needs and improving their workflow. This continuous review leads to incremental improvements without fixed retrospectives as in Scrum.
- Planning is dynamic and less burdensome than in Scrum. Instead of a fixed sprint backlog, teams can prioritise tasks on demand and adjust work as availability and demand change. This makes planning leaner and faster, without losing sight of long-term goals.
- It is particularly suitable for dynamic environments where requirements change often, such as maintenance, support or continuous development projects. Teams that have both continuous tasks and larger, planned milestones benefit from the flexibility and adaptability that the approach offers.
- As with Kanban, a key advantage is the visualisation of the workflow using a Kanban board. The board makes the progress of tasks and potential bottlenecks visible, leading to better oversight and team transparency. It helps the team to see at a glance where there are problems and where resources could be deployed more efficiently.
- Unlike Scrum, which prescribes fixed responsibilities, Scrumban allows teams to work without fixed roles if that better suits the team. This self-organisation can increase efficiency when responsibilities are divided flexibly.
- Since Scrumban is based on continuous flow and not on fixed sprint cycles, teams can react quickly to changes. New requirements can be added and prioritised immediately, without having to wait for the end of a sprint. This makes the approach particularly useful in projects where requirements change often and quickly.
And last but not least, teams can better structure their long-term, medium-term and short-term tasks through bucket-size planning. This makes it possible to pursue strategic goals while also reacting flexibly to short-term requirements. This maintains the balance between strategic direction and operational efficiency.
What are the challenges of working with Scrumban?
Although Scrumban is a flexible and adaptable method, it also presents some challenges that teams should be aware of when using it. These difficulties often result from combining Scrum and Kanban principles and from the flexibility that Scrumban offers. Here are some of the most common challenges:
- Since Scrumban, unlike Scrum, does not prescribe clearly defined responsibilities such as the Scrum Master or Product Owner, there may be uncertainty about who is responsible for which tasks. This lack of clarity can lead to a situation where no one feels responsible. Teams coming from Scrum may need to adapt the way they work and establish clear responsibilities themselves.
- Without sprints, it can be difficult to monitor progress and meet deadlines. Without clear time frames, there may be a lack of pressure to complete tasks by a certain point in time, which risks projects getting stuck. There is a challenge in finding the right rhythm to complete tasks efficiently, without the rigour of a sprint cycle.
- Despite the use of WIP limits, it can be difficult for teams to set and adhere to these limits. When too many tasks are worked on at the same time, overload and multitasking can occur, reducing productivity and diluting focus. Teams often have to experiment to find the right number of parallel tasks that is both feasible and efficient.
- Without fixed meetings, there is a risk that continuous improvement will be neglected. Without regular review, the team may fail to recognise stuck processes and make no improvements. It takes discipline to constantly question and adapt processes without fixed periods for reflection.
- In Scrumban, prioritisation often occurs dynamically, based on which tasks are available next or which requirements are emerging. The lack of a fixed sprint backlog can cause teams to struggle to set priorities and keep track of important tasks. This flexible prioritisation can seem chaotic in environments with many rapidly changing requirements if clear criteria for prioritisation are not set.
- Without fixed sprint cycles or a strict focus on long-term goals, there is a risk that teams will focus too much on short-term tasks and neglect strategic issues. Additional planning is needed to ensure that long-term goals are still being pursued.
- Additionally, teams may find it challenging to find the right balance between Scrum and Kanban. It is important to iterate and adapt the way you work to find out which elements from both approaches work best and how they can be optimally combined.
Conclusion: Working with Scrumban presents a number of challenges, particularly with regard to the clear definition of roles, dynamic prioritisation and the lack of fixed time frames. Nevertheless, the approach also offers teams the flexibility to continuously improve their processes and make them more efficient. To overcome these challenges, teams need to be disciplined, regularly question their working methods and respond flexibly to project needs.
Is Scrumban a Scrumand or a Scrumbut?
To answer this question, it is worth taking a brief look at the definitions of the terms scrumand and scrumbut.
The extension of the Scrum framework with elements or methods is called a Scrumand. The term goes back to ‘We use Scrum and…’. So if Scrum is extended by visualising the workflow using a Kanban board and applying WIP limits, it is a scrumand.
A Scrum project without individual Scrum elements is called a Scrumbut. The term is derived from ‘We use Scrum, but…’ If an organisation uses Scrumban without using iterations and responsibilities, it is a Scrumbut. At the same time, however, it is also a Scrumand, because the use of workflow visualisation and workload limitation adds additional aspects to Scrum.
What is a feature freeze?
In the context of Scrumban (and other agile methods), a feature freeze refers to the moment when it is decided that no new features or major changes will be added. Instead, the team focuses exclusively on completing the work in progress, correcting bugs or testing the existing code to ensure a stable product increment.
In Scrumban, a feature freeze can take place before an important milestone or release. Since Scrumban usually does not have a fixed sprint rhythm, but rather a continuous workflow with dynamic prioritisation, a feature freeze can help to create clarity and stability before a specific goal (such as a product release). It is introduced to ensure that all ongoing work is completed and the product is stable before further features are implemented.
What is software triage?
After a feature freeze, when no new features are added to a release, a software triage can be performed. Here, the project manager or team decides which of the features or tasks already in development should be completed by the upcoming project deadline and which should remain unfinished. The goal is to ensure that the team focuses on the critical features and completes them on time, while less important features may be postponed or cancelled.
The process of software triage is as follows:
- All features that are already in the workflow are reviewed. Each feature is evaluated in terms of its importance to the project. Features that are absolutely necessary (e.g. for market launch) are classified as critical, while others are considered optional or less urgent.
- The extent to which each feature has been developed is reviewed. Features that are almost complete tend to be prioritised, while features that still require a lot of work may be postponed.
- Based on the evaluation, the managers or stakeholders decide which features absolutely must be completed by the project deadline and which may remain unfinished or be dropped from the current release.
- The prioritisation is then mapped in the sprint backlog or in the short-term bucket and the team proceeds with the processing.
Ideally, the project participants will already have an overview of the agreed scope of delivery in advance, so that software triage does not occur in practice.
Impulse to discuss:
What challenges arise in Scrumban due to the lack of fixed roles such as the Scrum Master?
Notes:
[1] Scrumban: Essays on Kanban Systems for Lean Software Development
If you like the article or want to discuss it, feel free to share it in your network.
Here you can find additional information from the t2informatik Blog:
That’s no Scrum
Stumbling blocks in the introduction of Kanban
Kamishibai and Kanban for (too) interdisciplinary teams