Along with ‘brunch’ and ‘motel’, scrumban is a blend of two words that, when put together, creates something new. In this case, the two words are ‘Scrum’, and ‘Kanban’.
Scrum and Kanban are two different types of Agile methodology, which sit alongside Extreme Programming (XP), Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (AUP), Crystal, and Dynamic Systems Development Method (DSDM).
They’re all fundamentally similar (each focuses on planning, improvement, and delivery) albeit with a few subtle differences. In most cases, teams will use a blend of two, depending on the type of project they’re working on.
Before we get into Scrumban, let’s take a look at Scrum and Kanban, and the differences between the two.
What’s the difference between Scrum and Kanban?
Scrum is the most popular Agile methodology for software development. It involves small teams completing tasks in timed iterations, called sprints. The sprints contribute to the wider project, which will have its own completion date.
Kanban is a popular choice for maintenance projects. It focuses on continual improvements gradually over time, rather than an overarching end-goal. Tasks are completed on a rolling, ad-hoc basis.
Scrum and Kanban often go hand-in-hand. And while they do both rely on an iterative way of working, they are fundamentally different.
While both require a project manager, Kanban has no predefined roles within the team, whereas with Scrum, everyone has a set role.
With Kanban, products and processes are delivered continually or ‘as needed’. There isn’t usually an end date. Scrum is defined by set periods of time, called sprints, in which the product or service must be delivered.
Changes or modifications
Those using Kanban can make changes mid-project. With Scrum, changes are made only at the end of each sprint.
Both rely on a ‘pull’ method of working. With Scrum, you select the work you’ll be doing for the next sprint, then work up until the end of the sprint — by which time, your workflow should be empty. With Kanban, you accept tasks as soon as they’re ready. The work keeps flowing, and you can change items in the queue as needed.
With Kanban, productivity is measured in ‘cycle times’ aka, how long it takes to complete a task from beginning to end. With Scrum, each Sprint is measured against the success of the one before it.
Kanban is best for projects with varying priorities. Scrum is better suited to teams with set priorities that are unlikely to change much over time.
Check out our in-depth guide to Scrum and Kanban boards here.
Some teams find Scrum too restrictive for an Agile way of working, while simultaneously finding Kanban too lacking in structure. This is where Scrumban comes in.
What is Scrumban?
Scrum + Kanban = Scrumban , and it combines the best features of both.
It was initially introduced as a way to transition teams from one to the other, but has since become a methodology in its own right.
With Scrumban, Scrum’s iteration planning is combined with Kanban’s pull system.
- Uses the iteration structure of Scrum (albeit a more flexible version)
- Uses the continual improvement process of Kanban.
Rather than holding daily review meetings and estimating the scope of work for every single iteration, teams just need to make sure the backlog is limited to a fixed size that can run down to zero before the next planning stage begins.
A backlog is a list that prioritizes all the features that make up a product or project. It also includes things like bug fixes (in software development) and feature changes.
Iteration planning can happen at regular intervals, but unlike with Scrum, these intervals can be flexible. The goal is to complete the available tasks as they’re ready, rather than determine the number of tasks before work begins. This smooths out the workload process and reduces time spent on iteration planning, leaving more time available for quality control.
And, if a piece of work is marked as ‘complete’, but isn’t of high quality, that single task can be sent back on repeat until it’s ready. (A cause-and-effect diagram can come in handy here if issues keep occurring.)
What are the advantages of Scrumban?
- A more flexible, ‘just-in-time’ way of working for those previously using Scrum
- More structure for those previously using Kanban
- A shorter lead time
- Continuous improvement and minimized waste
- Less time spent on meetings (for those previously using Scrum)
Scrum vs Kanban vs Scrumban: which one should you use?
As with every methodology, Scrumban works better with some projects more than others.
If you work in a company where clients play a part in the development process and deadlines are important, then Scrum is the one for you. If you work primarily in a maintenance environment, where jobs are ongoing and development doesn’t play a key role in your output, then choose Kanban.
For those who experience frequent priority changes, find Scrum too limiting, want to add pull features or who fail to meet the time constraints due to lack of resources, then Scrumban is a good option.
Which methodology you choose ultimately depends on the type of project and how your team works. Whichever you go for, it’s important to follow best practices to have the best chance of success.
Regular team communication sits at the heart of this. Investing in a web-based project management tool is a good option for helping teams and stakeholders collaborate because individuals can check in on the projects’ status from wherever they are. Team members can store all their notes in one single place, while project managers can set up automatic notifications to let them know when a task’s been completed, or if one’s falling behind.
Backlog — our own project management tool — can be used for all three approaches. Bug and issue tracking features make it easy to monitor quality and improvements, while Gantt charts, burndown charts, and Kanban-style boards mean you can see which tasks are in progress and which have been completed. It also includes task features designed to help you create, prioritize, and assign tasks — which makes the whole project that little bit more collaborative, whether you’re working via Scrum, Kanban, or a blend of the two.