The world is full of combinations that complement one another, each part enhancing the other to create a partnership that’s greater than the sum of its parts. Scrumban, a hybrid methodology, brings together the strongest components of both Scrum and Kanban to form a powerful hybrid methodology.
What is Scrumban?
Scrumban is a hybrid project management methodology that involves applying Kanban systems within a Scrum framework. The goal of Scrumban is to allow an Agile team to make pragmatic choices about how they get things done based on their situation.
When a Scrumban methodology is implemented, it becomes much more difficult to describe the results succinctly, because each and every rollout of Scrumban is unique. The systems in which teams find themselves dictate many of their choices, and Scrumban offers the flexibility to create a hybrid Agile methodology that fits within those systems and makes them better.
When using Scrumban in project management, your objective is to meet the needs of the team and the organization, not to optimize for a particular practice. Scrumban is also built to expand as the Agile team grows in maturity. For example, it can easily embrace lessons from systems theory and the theory of constraints.
Scrumban vs Scrum
Scrum was designed as a more efficient, more effective means of managing the work done by teams, and Scrumban hangs onto this team-centric approach. The team remains in charge of planning its work and deciding how to execute it. It’s also the primary mechanism for process improvement, engaging in regular retrospective meetings.
Those retrospectives could happen at the end of a Sprint, just like they do on a Scrum team, but they might not. Some Scrumban teams maintain the Sprint Timebox, using it to govern the cadence of their planning, delivery, and retrospectives.
Others find that other components of the system can replace Timeboxing, and they move to a continuous delivery model more akin to the pull-based Kanban methodology.
Scrumban vs Kanban
One of the most common complaints about Scrum is that it exposes problems without providing solutions. There may be issues within the team, or issues in the interaction between the team and the organization at large. In fact, some organizations come to blame Scrum for causing the problems, when in fact all it did was bring them to the surface.
Scrumban maintains this ability to showcase shortcomings, but by adding Kanban to the mix, it introduces possible solutions to the problems it exposes. Kanban focuses heavily on visualizing workflow via a Kanban board, which looks like this before any work gets added:
After the team starts tracking its work on the board, it becomes clear very quickly where bottlenecks are forming. As the team gets more experienced setting its WIP limits, these constraining points will become even more obvious.
Now the team can clearly identify the point in their process where the process is breaking down and address the problem, rather than simply lament their poor velocity every couple of weeks during the Sprint retrospective meeting.
On-Demand: Four Steps to Streamline Marketing Workflow
Whitepaper: The Manager's Guide to Mixing Agile and Waterfall
More: Scrum vs. Kanban - Key Differences
The 4-part Scrumban kickstart event
The first step to using this adaptive approach is to run a Kickstart Event—a meeting in which the team will nail down the foundational elements of Scrumban so they can start using it to manage their work.
Like Kanban, Scrumban is designed to fit within your current work management approach, which means you don’t have to change anything about how you work before you implement it.
An Agile coach can guide you through an intensive Kickstart that includes exercises and detailed walkthroughs of all the intricacies of Scrumban, but if you want to handle it on your own you can boil it down to just four steps:
- Visualize the workflow
- Identify work types & build the backlog
- Set preliminary WIP limits
- Schedule major cadences
Visualizing the Scrumban workflow
Many Agile teams use a Kanban board like the one above to map what’s up next, what they’re working on now, and what they’ve completed, but during a Scrumban Kickoff we want to get more specific.
We want the whole team to discuss how work happens, including:
- Where does it come from?
- Who makes and receives the requests?
- What kind of approvals need to happen?
- Where does work go when the team is done?
- Does work need to be revisited in the future?
All of this information then needs to be reflected on the board. If you’re doing a Scrumban rollout for a large team that handles several different kinds of work, then you may want to create two or three distinct workflow visualizations.
The goal of visualizing the workflow is to create the simplest version of the board that will still accurately reflect the work being done. Seven columns, 10 if you’re handling very complex projects, should be all that you need. A casual passerby should be able to glance at the board and get a sense for how things are going.
Identifying work types and building a backlog
Work types are like buckets into which you can put all the work your team has to do. As with all things Scrumban, you’ll need to base your work item types on the unique situation you’re working in, but consider these initial work types:
- Work that has the most value for customers or partners
- Work that is demanded the most and the least
- Work that is usually more urgent than other types
- Work that is most and least aligned with the team’s ultimate purpose
As you choose your work type buckets, use them to categorize the team’s current workload too. This categorized list can then be turned into your first backlog, a prioritized to-do list from which the team pulls its next round of work:
You may find that in order to project completion dates your team needs to estimate the size of work in addition to categorizing it, particularly in the early days of a Scrumban rollout. But as time goes on it’s likely that you’ll begin to understand that Work Type 1 tends to take six days to finish, while Work Type 2 can get done in just two or three days.
This general sizing often eliminates the need for task estimation with Story Points, a Scrum practice that troubles many Agile teams. Combining work types with WIP limits makes delivery dates even more precise, and estimation even less necessary.
Preliminary WIP limits
Work in Progress (WIP) limits govern how much work a Scrumban team can have in any given state at once:
If you have a WIP limit of five on your In Progress column and there are already five things being worked on, no one on the team can begin new work until something moves out of that column and into the Done column. WIP limits are enormously powerful, but one of their most important tasks is to show where bottlenecks happen.
It can be tempting to set WIP limits of one or two on every column, but when choosing your first WIP limits start a little higher than you think you should and work your way down. This will allow enough work to enter the system to reveal bottlenecks in the workflow; very low WIP limits not only slow down the flow of work, they create multiple idle team members.
Scheduling major cadences
As the final step in your Scrumban Kickstart, you need to settle on some initial cadences to govern your team’s process. You can discuss releases and delivery of completed marketing campaigns, planning, backlog refinement, and other typical Scrum ceremonies, but at the very least you need to tackle three core cadences:
- Sprint length
Scrumban stand-up meetings
The cadence of the stand-up meeting is pretty much already decided for you: nearly all Agile teams will get the most out of this meeting if they have it every day. However, Scrumban teams typically benefit from using the Kanban style of stand-up. This format foregoes individual updates on what team members did yesterday, what they plan to do today, and any blocks impeding their progress.
Instead, a facilitator walks the team through the Kanban board in reverse order, from Done to the Backlog, discussing notable work items. This type of stand-up should still take only 15 minutes, but not every team member has to speak.
A new Scrumban team will benefit from regular Retrospective meetings, so they should be held at least every two weeks. Scrumban teams aren’t beholden to Sprints, however, so you can also hold impromptu Retrospectives if there are moments of learning that you want to apply in advance of your next scheduled meeting.
Finally, the team should determine if they want to start out by using Sprints. If so, they should end their Kickstart meeting by deciding how long those Sprints will be.
For Scrumban teams engaged in continuously delivering marketing work, such as social media or blogging, Sprints may not be necessary. Those that feel more comfortable with Timeboxes and deadlines can start with the traditional two-week Sprint and adjust its length as they see fit.
Whitepaper: How to Become an Agile Agency
Whitepaper: Agile Marketing for Creative Teams
Scrumban: a powerful combination
Will this potent combo be the magic bullet for your team? Scrumban boasts many of the strengths and few of the weaknesses that plague its predecessors, Scrum and Kanban. But its flexibility can be intimidating for teams new to Agile and lacking an internal coach or advocate. If structure and certainty will help you get started, Scrumban’s adaptability might be a detriment.
In the end, it’s up to each department to take a long, hard look at all the available methodologies and decide which seems likely to meet their needs. The good news is, even if your first choice doesn’t work out, you can always pivot to another. Agility is a constant work in progress, and your team’s methodology should be too.