Scrumban guide: 9 things to know before you start

Scrumban is an Agile methodology that combines Scrum and Kanban approaches to software development. In this post we'll go over what Scrumban is, how it's different from Kanban and Scrum, and nine things you need to know about it before you try it out for your team.

What is Scrumban?

Scrumban is the brainchild of Corey Ladas, who first introduced the concept in 2009 when he published “Scrumban: Essays on Kanban Systems for Lean Software Development”. In this book, he aimed to address the weaknesses in Scrum while asserting that the integration of certain Kanban principles would solve those pain points.

Scrumban was originally intended to help teams transition from Scrum into Kanban. However, many teams found that the midpoint was actually a great place to stay. For that reason, you’ll find nuances in the way different companies implement Scrumban.

Scrumban vs. Kanban vs. Scrum

Because Scrumban is a hybrid of both Scrum and Kanban, it’s helpful to first review what Scrum and Kanban are.

All three methodologies fall under the wider umbrella of Agile methodology.

By design, Agile is meant to adapt to change and uncertainty. However, Scrum is the most rigid of the Agile branches. It is characterized by cross-functional teams working in sprints, which are timeboxed iterations that last 1-4 weeks (typically 2 weeks). Each sprint is structured around a clearly defined goal, and once a sprint has begun, you cannot add any more tasks.

On the other hand, Kanban relies more heavily on visualization, and instead of working in sprints, teams aim for continuous workflow. A Kanban board is a visualization tool in which the team puts tasks onto cards (one task per card) and places them under the following columns: to-do, in progress, and done. It allows teams to keep track of progress as well as limit work in progress (WIP) so that members aren’t working on too many tasks at once.

Now that we’ve seen Scrum and Kanban at a glance, let’s take a look at Scrumban.

The core characteristics of Scrumban

To get a deeper sense of what Scrumban is and what it can offer in terms of project management, let’s break down some of its key characteristics.

1. Scrumban is all about continuous improvement.

Not all teams work their best under the rigid framework of Scrum due to its stop-and-go nature.

On the other hand, an essential part of Kanban methodology is kaizen, which is the Japanese concept for continuous improvement. Scrumban adopts this idea and marries it with the structure that Scrum provides.

2. Scrumban is visual.

Two words: Scrumban board. A Scrumban board is a visual representation of your team’s process workflow. On a single board, either physical or virtual, everyone can see which tasks they have yet to start, which tasks are currently being worked on, and which tasks have already been completed.

It’s similar to a Kanban board in that it doesn’t get reset after each iteration (as happens in Scrum). Instead, it persists throughout the entirety of the project. Plus, a Scrumban board isn’t just for visualizing; it also encourages transparency, accountability, efficiency, and teamwork.

3. Scrumban isn’t prescriptive when it comes to teams and roles.

In Scrumban, there’s no formula for how your teams should look. To put that into perspective, let’s revisit Scrum. According to Ken Schwaber and Jeff Sutherland, creators of The Scrum Guide, a Scrum team functions optimally when comprised of 3-9 people. Roles are predefined: Scrum master, product owner, and development team members. In addition, teams are designed to be cross-functional rather than specialized — meaning that each member offers unique yet complementary skills to their team as a whole.

In contrast, Scrumban teams are not structured around specific roles or group sizes.

4. Scrumban planning is on-demand.

Planning sessions aren’t scheduled at regular intervals as they are in Scrum. (For instance, sprint planning in Scrum might occur every two weeks, between each sprint.) In the Scrumban methodology, team members will hold a planning session once their backlog drops down to a certain number. When that happens, that’s called a planning trigger.

Remember that a major goal of Scrumban is to achieve flow. If teams wait until there are zero items in the backlog to plan for future work, that of course, disrupts their flow.

5. Scrumban manages what’s on the team’s plate.

Each type of Agile methodology has a system in place to control the workload at any given time. After all, who likes being overwhelmed? Scrum handles this by saying, “This is how long each sprint/iteration will be, and this is how many tasks you can do in each sprint.”

On the other hand, Kanban and Scrumban adopt WIP limits or work-in-progress limits. That means that teams can only be working on a preset number of tasks at once. The Scrumban board, of course, reflects that limit by showing the number of cards on the board.

6. Scrumban meetings are somewhat structured.

Scrum involves a systematic approach to meetings — aptly named “ceremonies.” There’s no such standard in Kanban.

Scrumban takes the middle road. Teams come together for daily standup meetings that last about 15 minutes, but other meetings (like retrospectives) occur on an as-needed basis.

7. Scrumban emphasizes task prioritization.

If you’ve ever been part of a Scrum team, then you know that story points are a major part of the process. Simply put, story points are units of measurement that tell you how much effort each of the user stories will require. Story points allow Scrum teams to plan out what work they’ll include in each timeboxed sprint.

Because Scrumban teams don’t typically work in timeboxed iterations, there’s no need to estimate their tasks with story points. Instead, development teams decide what to do next by order of priority. When there’s room for another card under the work-in-progress column on the Scrumban board, team members pull whatever item has the highest priority.

8. Scrumban is adaptable.

Scrumban is ‘adaptable’ in at least two ways. First, you can apply Scrumban in all types of contexts — not just software development.

Second, Scrumban is adaptable in the sense that teams have customized the process to better suit their needs, since Corey Ladas introduced it in 2009. That's why people implement Scrumban differently. For instance, some work in two-week iterations while others don't timebox.

9. Scrumban uses cycle time as a key metric.

Cycle time measures the time it takes to complete a task from start to end, and it’s the main way that Scrumban teams measure success. Don't confuse cycle times with lead times, which refers to the time between when someone requests a task to when your team delivers it.

To make the distinction clearer, think about ordering a drink at your favorite coffee shop. Lead time starts from the moment you place your order to the time you receive your brew. Cycle time doesn’t start until your barista picks up that first ingredient and starts actually making your order.

Moving forward

Scrumban is just one of the many methods under the Agile methodology. So how do you know if it’s right for you? Scrumban works ideally for teams who perform well with structure (a.k.a. Scrum) but also crave the flow element that Kanban provides. It also works great for teams who are transitioning between Scrum and Kanban, allowing them to smoothly adopt a framework rather than jumping ship. Whatever you choose, start with a comprehensive evaluation of you and your team’s goals.

‍