Have you tried to implement Scrum with your agile team and felt that the overall rules and strict schedule are actually hindering your productivity? Were you constrained by the non-flexible idea that nothing new or urgent can end up in the sprint? We all know that priorities can change, stakeholders’ requirements can fluctuate, and critical bugs can crop up at any moment. Maybe your team was unknowingly tweaking the rules, stopped sticking to the strict schedule, and started accepting new requests even during the sprint cycle. If that’s the case you might have been practicing a new Agile methodology, Scrumban, without even knowing! So what is Scrumban, exactly?
What is Scrumban?
As you probably guessed, Scrumban has something to do with Scrum and Kanban. Scrumban is an Agile development methodology that came to light in 2008 and was invented by Corey Ladas. He found some shortcomings in the Scrum framework and suggested improvements in his book, Scrumban – Essays on Kanban Systems for Lean Software Development.
Scrumban is a Kanban-Scrum hybrid, where Kanban principles are applied to the Scrum framework. In Scrumban, and similarly, in Kanban, the main goal is to take the tickets as fast as possible from ‘To-do’ to ‘Done.’
When talking about Scrumban we cannot forget to mention Scrum. Which principles are kept from Scrum and which are set aside?
Scrumban vs Scrum
Similarities
Work environment
Both work well in big projects, with multiple products and teams collaborating. Scrumban and Scrum also work well in fast-paced environments.
Time-based work
Scrum and Scrumban are both time-based with recurring intervals of scheduled work. Scrum is usually divided into 1-4-week sprints with clear sprint goals, whereas Scrumban is more fluid and focuses on continuous work with 1-year, 6-month, and 3-month buckets.
Differences
New roles
Scrum requires the team to change and adapt to new roles, like Product Owner, Scrum Master, and Scrum Team. Scrumban lets the team keep their previous roles.
Agile events
The Scrum framework outlines strict rules when it comes to Agile events like Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retro. In Scrumban the Agile events are optional but sometimes encouraged, especially the planning and retro sessions that can be done on demand.
Product Owner’s role
In Scrum, Product Owners have the sole responsibility for Product Backlog, and most of the time they have the final say. In Scrumban there is no such role, as each team member has equal responsibility and input when it comes to prioritization of the work items.
Daily progress
In Scrum, daily progress is tracked during Daily Scrum meetings. The team can assess the current situation, making sure the sprint goal can be achieved and the features will be released according to a predefined schedule. Daily Scrum event helps to plan ahead and find solutions for any blockers that prevent the team from going forward. In Scrumban you’re not required to keep a tight schedule of agile events and the daily progress might be more difficult to track, however, Scrumban doesn’t impose Sprint goals, and the current status of tasks can be visible on a Scrumban board if it’s updated regularly. Scrumban requires more ad hoc meetings where developers mention the blockers and discuss possible solutions.
Sprint scope
In Scrum the Sprint scope is sacred. It’s not impossible to alter it, however, that will require good negotiating skills on your part. If unexpected changes in requirements or critical bugs crop up – you could do replanning, or stop the current Sprint altogether, however, this needs to be discussed and agreed on with the Product Owner first. Scrumban offers a lot more flexibility, for example, tasks of any size can be taken on an ongoing basis without any negotiations needed, yet there could be a certain ‘feature freeze’ implemented just before a release deadline.
Estimation
In Scrum, you’re required to estimate each user story and decide with the team how much effort is needed before jumping into the Sprint. Even the more radical ‘NoEstimate’ approach introduced by Vasco Duarte, which can work in Scrum, requires you to decide if the product backlog item is small enough to fit into the Sprint.
In Scrumban you can say goodbye to estimation, story points, or planning poker but you need to be aware of the potential risks this might entail. The real value of estimation is not only assigning story points but having insightful discussions with the team about the requirements and complexity of the tasks, and how much effort and time is needed to complete them.
You might feel that estimation sessions are critical to the team in case
- you need to discuss slicing a bigger backlog item into smaller pieces when you negotiate the capacity for a given Sprint and can’t commit to completing the whole task at once
- you want to keep tabs on the metrics, check the teams’ performance, and identify any obstacles
Performance metrics
In Scrum, the performance metric is velocity whereas in Scrumban it’s the average cycle time and lead time. Velocity simply measures the amount of work a team can deliver during a Sprint and cycle time tells us how much is needed to move the task through different parts of the process (like testing, for example). Lead time refers to the overall time needed to complete the task from the ‘To-Do’ list.
Prioritization
In Scrum, prioritization happens during backlog refinement when stories are estimated and ready to be pushed to the next Sprint, whereas in Scrumban prioritization usually happens during an on-demand planning session.
Task size
In Scrumban the task size doesn’t matter as the team is not locked into Sprints. Any task size is welcome, however, in Scrum only the tasks that can be delivered in a particular Sprint are allowed.
Scope limits
In Scrum, Sprints limit the amount of total work to be done and in Scrumban Work in Progress (WIP) and ‘To-Do’ limits are set to restrict the number of tickets currently worked on.
Assignees
In Scrum, tasks are usually assigned to a specific team member during either Backlog refinement or Sprint planning, whereas Scrumban is based on the pull system where each team member chooses the ticket they want to work on. In Scrumban, ‘buffer’ columns between process stages are advised as well as a trigger point (especially in the ‘To-Do’ section) to make sure the work items are not pushed but pulled to the next phase.
Scrumban vs Kanban
Similarities
Board
Tasks are visualized on a board that gives a clear overview of the Work In Progress and the actual capacity of the team. On a Kanban board, we will usually see ‘To-Do’, ‘In-Progress,’ and ‘Done’ sections. In Scrumban we can add additional columns like ‘Dev,’ ‘Ready to Test,’ and ‘Test’ to highlight more phases in the development process.
Workflow
Both Scrumban and Kanban methods deliver value incrementally and rely on the continuous flow that is flexible to the changing environment, project scope, and unexpected urgent requests.
Pull system
In both Scrumban and Kanban, the team uses a so-called pull system where tasks are taken one by one from the ‘To-Do’ list. There is no push from a project manager to complete specific tasks, the team decides on the priority of the items and works freely, pulling the new tasks to the ‘In-Progress’ sections once WIP limits allow it.
WIP limits
In both Scrumban and Kanban WIP limits are applied. We all know that it’s far easier to start a task than to complete it. WIP limits ensure that the team can spot bottlenecks early on and work together on solving them before taking new tasks on board. Without WIP limits, the team would find themselves in a sort of chaos, with lots of tasks that are started but not a lot of them being released. In Scrumban ‘To-Do’ limits can also be imposed to increase the efficiency of the workflow.
Estimation session
Both in Scrumban and Kanban estimation is optional and not required.
New roles
Scrumban and Kanban do not require the team to change and adapt to the new roles like in Scrum. Previous roles can be kept, which makes it far easier to implement.
Task size
In Scrumban and Kanban, any task size can be pulled and worked on, as there are no time-boxed Sprints.
Ease of adoption
Both methods are relatively easy to adopt, however, Scrumban is usually recommended for teams in larger organizations and those that are just starting out with Agile. The Kanban method, on the other hand, would not work well in bigger organizations with cross-team collaboration as it’s not very clearly defined. Scrumban gives more structure than Kanban but is also more flexible than Scrum.
Team members’ input
There is no Product Owner role in either Scrumban or Kanban, hence each team member has equal rights to decide which items to take from the ‘To-Do’ list and which tasks should be prioritized.
Release cycle time
Kanban and Scrumban are not time-consuming when compared to Scrum. Both methods enable the team to release items as quickly as possible as the team gains time by skipping estimation sessions and recurring agile events.
Performance metrics
Both in Scrumban and Kanban, the performance is measured by lead time and cycle time. In Kanban, the additional metric is throughput, which measures the amount of work released over a specific timeframe.
Differences
Time-based work
Kanban is not time-based whereas Scrumban has its work scheduled in 1-year, 6-month, and 3-month buckets. The 1-year bucket is for the long-term goals, the 6-month bucket for specific goals, and the 3-month bucket for all the tasks that have clearly defined requirements. The Scrumban team pulls the work items from the 3-month bucket only, for the next round of software iterations.
Prioritization
In Kanban prioritization is optional, whereas in Scrumban it’s always done during on-demand planning sessions where new items can be pulled in the ‘To-Do’ section.
Rules
Kanban is more flexible than Scrumban and can be adapted to teams’ needs, however, it’s also less concrete and might give an impression to less experienced teams that there is not enough structure.
Work environment
Scrumban is a good fit for large projects and cross-team collaboration, whereas Kanban is better for teams that do not depend on input from others. Scrumban might be a better option if the team is working on multiple products.
When to Use Scrumban
Scrumban is a good fit for agile teams that are just embarking on an agile journey. It also fares well in large organizations, with multiple products in the mix and a fast-paced environment. It’s better to use this method if your team doesn’t have direct pressure from management and you don’t need to stick to any strict deadlines, as the scope is not as clearly defined as in Scrum.
Scrumban is a preferred method if you want to focus on delivering value as quickly as possible to the client without dedicating the time to estimation sessions or agile events. Scrumban is less complex to implement than Scrum, so it could be a good fit for startups that can’t budget for new roles like Product Owner and Scrum Master. This method is good for loyal and motivated teams as the individual team member’s effort is harder to track.
You can always start with Scrumban and if you need more structure or your stakeholders start pushing for tighter deadlines, you can move to Scrum. Scrumban was actually invented to show an alternative to Scrum, as some teams find that overall rules and processes slow them down.
When to Use Kanban
Kanban is good for teams that are following the same process time and time again. It’s a good fit for marketing teams, support, and manufacturing. It could work well with more experienced software development teams that can embrace the grey areas. Kanban gives a lot of freedom and personalization, it gives room for teams to be more flexible in production and at the same time takes away the complexity of the process. Your team can decide to keep the retro sessions but schedule them every 10 items shipped, for example.
Kanban might be less effective in cross-team collaboration when your team needs to wait for input from another to finish a particular task. This method can also fare better in the remote setup, with the use of an online Kanban board. Physical boards might not be updated regularly and this could cause issues for the team when two people start working on the same item. Kanban is also a good option for teams that keep receiving requests that vary in size and priority and there is a common understanding that the release length will fluctuate.
You can choose Kanban if your team doesn’t have any strict deadlines and features can be released when they are ready. Kanban is better for tasks that can be completed without dependencies on other tasks. You can use this method when the speed to market is the number one priority.
Check out our blog and learn more about the principles and history of Kanban.
How to get from Scrum to Scrumban
Now that you have a clearer picture of the principles of Scrumban and the slight differences with Kanban, you might be wondering how to easily transition from Scrum to Scrumban. Let’s go through the following steps:
- First, get your hands on a Scrumban board. It could be a physical board or an online board (Kanban board can be easily tweaked, with additional columns added to the mix like ‘Dev,’ ‘Ready to Test,’ and ‘Test’).
- Apply WIP limits. Each developer, for example, is allowed to work on a maximum of three tickets at once.
- Make sure buffer columns are applied where necessary. For example, introduce a ‘Ready’ section in the ‘To-Do column’ so the tickets are not pushed from the ‘To-Do’ section but pulled from the ‘Ready’ column.
- Don’t assign tickets to team members, like in Scrum. Let your team members choose their tickets. Once they are done, they can pull a new one from the ‘Ready’ section of the ‘To-Do’ list that has already been prioritized during the planning session.
- Don’t estimate. In Scrumban we can forget about story points or planning poker. Scrumban is more about prioritizing the tasks rather than sizing work like in Scrum, in order to boost the efficiency and speed to market.
- Implement planning sessions on-demand, whenever the situation asks for it. You can apply a trigger point in the ‘To-Do’ section. Whenever there are no items left and new tickets can go above the trigger point, the new planning session kicks off.
- You can keep sprint review and retro from Scrum if you wish but without the need to stick to a strict schedule.
Check out this video from Gary Straughan, the founder of Development that Pays, which outlines all the steps.
Benefits of Scrumban
- It gives the team more development time.
- It’s flexible and can include additional urgent tickets during the workflow.
- It relies on the pull system, where work items are ordered by priority and value delivered to the customer.
- It can speed up the development pace by making sure more items are shipped in less time.
- It shows where your team is stuck. It gives a clear picture of which stage slows the release cycle.
- It’s easy to adopt and relatively lightweight with straightforward rules.
- It promotes equal say in the team as the Product Owner’s role is not required and the Product Owner doesn’t determine the priority of the user stories.
- It can give more sense of accomplishment. There are no sprint goals that may sometimes frustrate the team if the goals are not achieved. The work is done on a continuous basis with ongoing improvements, even if the requirements change in the meantime.
Key Takeaways
The biggest question is — which one to choose? Should I go with Scrum, Scrumban, or Kanban? First off, each team is different and each team might tackle different problems. Before deciding on Scrum, Scrumban, or Kanban, ask yourself and your team these simple questions: What problems do we have? Which issues would we like to resolve? Is it the code quality? Maybe it has something to do with stakeholders, bottlenecks, slow speed to market, failed deadlines, or prioritization of the tasks? When you get the answers to these questions, it’ll be much easier to make a decision.
Frameworks and methods are for teams, not the other way around. Don’t try to shape your team so that it fits the process; rather, listen to your team and shape the process to suit your particular needs. The nature of agile is flexibility, no one says you have to stick to one framework or methodology even if it doesn’t work. Take each one for a test run and compare your team’s sentiment, the quality of the final release, and the speed by which it reached your customers.
Happy coding! Oh, and don’t forget to check our Scrum vs Kanban vs Scrumban Cheat Sheet below.
Scrum vs Kanban vs Scrumban Cheat Sheet
