What is Scrumban? | Definition + 5 Common Scrumban Myths

Scrumban is one of the biggest methodological mysteries in the world of Agile.

In 2008, Corey Ladas dropped a bomb in an Agile environment when he first described Scrumban in his book. Since then, a lot of myths have emerged around it.

In this article, you will get a basic understanding of Scrumban and review the experiences of Scrum Teams that decided to flirt with Kanban by busting 5 Common Scrumban Myths:

• Myth #1: Scrumban is a combo of what suits you in both Kanban and Scrum.
• Myth #2: In Scrumban, you need to break down the tasks as much as possible.
• Myth #3: It is impossible to predict the delivery of increments.
• Myth #4: There are no/or much fewer meetings in Scrumban.
• Myth #5: Scrumban is reserved for maintenance development.

Trends in the Agile world

Before we answer the “What is Scrumban?” question, let’s discuss trends in the Agile world.

If you’ve ever dealt with the IT industry, you must have come across the most popular Agile framework – Scrum.

According to 15th State of Agile Report, Scrum is the most widespread approach around the world in 2021, as almost 66% of the IT world applied the Scrum framework to deliver value to customers.

No wonder – it is the easiest way to kick off projects with complex products. (Spoiler: easy to understand, but difficult to implement).

The good old Kanban contributes to only 6%, whereas our mysterious Scrumban accounts for 10%. You might think that it is not a big chunk to be concerned with, but the trend to combine and compress different practices is definitely on the rise.

What is Scrumban?

Scrumban definition: Scrumban is an Agile development methodology that is a hybrid of Scrum and Kanban.

See also: What is Scrum?

Where is Scrumban from?

On the Internet, you might come across a lot of combinations of Scrum and Kanban, sometimes even contradictory ones. In my analysis, to have better clarity on which Scrumban we are talking about, I am going to refer to Scrumban, understood as the practices recommended by Corey Ladas.

Let’s get back to the roots.

In 2008, Corey Ladas, the father of Scrumban, published a ground-breaking book titled- no surprises –  “Scrumban”. He triggered the discussion on taking the best of two worlds: Kanban and Scrum.

Initially, he experimented with his teams on transforming from Scrum to Kanban because he noticed that some of the Scrum elements limited his teams’ efficiency.

Gradually, taking advantage of Kanban’s focus on continuous development and seamless throughput, Corey Ladas ended up creating a new hybrid.

• The new approach had more relaxed rules than Scrum and let the teams experiment and adjust to their needs.
• There are no requirements regarding team size, which is opposite to Scrum’s recommendation of not exceeding 10 team members.
• Scrumban teams can rely on Scrum in terms of basic terminology, meetings structure, and roles, but none of it is implied.

However, the biggest difference to Scrum is that Scrumban teams are allowed to only plan when required, instead of having determined planning times at the beginning of each Sprint.

The same on-demand approach applies to Review and Retrospective meetings. According to Scrumban supporters, each Team is able to decide by themselves when the best time for demo or collecting feedback is – and how often to do it.

Scrum vs. Kanban vs. Scrumban

The table below shows this comparison in a nutshell:

	Scrum	Kanban	Scrumban
Rules	strict	more relaxed rules	moderate-strict rules
Team size	6-9 people	unlimited	unlimited
Roles	Product Owner, Scrum Master, Developers, Stakeholders	no specific roles required	no specific roles required
Meetings	Planning, Review, Retrospective, Daily	daily stand-up Kanban meetings	daily stand-up and any other meetings on demand
Cycle	1-4 week Sprints	continuous flow	flexible or fixed iterations

Corey has admitted many times that, as with every Agile method, you have to experiment and find your feet in the one that suits your needs. The practices he described might evolve and adapt to trigger the best efficiency, as it is not a rigid or well-defined framework.

That is why Teams have interpreted Ladas’ Scrumban as any kind of hybrid model that would have a bit of Scrum and a bit of Kanban.

As a result, Scrumban with no clear guidelines has become a vague nihilistic Agile approach where Teams can resign from anything that they do not like about either Scrum or Kanban.

It’s not the point, though, and can lead to total chaos.

5 common myths about Scrumban you should know as an app owner

Let me walk you through the most common Scrumban myths that you should watch out for when considering Scrumban.

Myth #1: Scrumban is a combo of what suits you in both Kanban and Scrum

Obviously, you might go wild and pick and drop whatever you like or dislike from any method, but it can be extremely risky.

First of all, it is important to build the same understanding of the rules we are obligated to follow within the team. If you kick off a project with no clear ways to verify goals, communicate obstacles and improve efficiency, it’s the straight way to lose track of everything.

Of course, you might go with the tailor-made combinations of different methods and practices right from the beginning, but it is much less effective than the evolutionary approach. By this, I mean: it is much safer to start from a well-defined, widely known framework and, on the way, add and modify practices that work for your team step by step.

Pro-Tip

If your team has had no experience with Scrumban, it is much better to start with Scrum and then, on the way through, gradually experiment with Scrumban elements if you need to.

Myth #2: In Scrumban, you need to break down the tasks as much as possible

Scrumban teams favor the Kanban approach to show the complexity of backlog items. Instead of using story points, developers break down the backlog to more or less similarly sized items. As we do not show the complexity of items in story points, how do we provide the best transparency of the work?

If you have a task that looks like 7-10 days worth of effort, will it be valuable for everybody if only one person works on it?

One might think that yes, as there will be no context-switching and full focus will be ensured. But, in fact, such tasks get stuck in “in progress” for more than two weeks, as it usually means that they are not well refined and miss some prerequisites. Likewise, if the developer goes on holiday or gets sick, taking over the task is much harder for their peers.

To avoid such risks, it is better to break down the tasks and let cross-functional teams pull the work and enable feature testing gradually.

How can you break down the backlog?

There is no one perfect answer, as each team and each project is different. It is always a good idea to experiment with the different size limits and choose the one that is most accurate for forecasts.

To sum up, don’t break down the tasks as much as possible, but as much as it works for your goals.

Pro-Tip

According to my observations, it is worth setting a limit of 1-2 days for each backlog item to implement. Bigger backlog items imply bigger complexity and risk creating a bottleneck in the workflow. For skeptics, explore more on the Elephant Carpaccio exercise.

Myth #3: It is impossible to predict the delivery of increments

One of the benefits of establishing Scrum is the idea that, after a few same-length Sprints, you should have some feedback on how much your team is able to develop (velocity). You can measure the velocity if developers estimate the tasks using, for example, story points. Based on these metrics, you should be able to have a rough forecast on how long the planned feature completion will take.

But how does it go with less fixed iterations and with no estimations? Don’t we lose control over what’s ahead of us?

Actually, Scrumban is packed with metrics and empirical practices as much as other Agile methods. How is predictability supported in Scrumban? There are three main rules:

• granularization of tasks
• work in progress limits
• metrics: throughput & cycle time

Scrumban teams usually give up on estimations in story points in favor of breaking down the backlog into granular, similarly sized items. It is up to the team how big the items are, whether it’s approximately 1 day or half a day of effort.

Having the backlog granularized, you can clearly see how the flow of work goes and intervene in case of any bottlenecks. Finally, based on these two metrics, you can estimate when the particular part of the backlog will be developed.

Throughput will tell you how many items the team is able to deliver in a specific time (e.g. 10 backlog items per one week) and, additionally, the cycle will give you insights on how much time is spent on an item from the “in progress” to “done” states.

Pro-Tip

If you are working with a mature team with established throughput, you can rely on forecasts based on a version report in Jira. The version report is based on the estimated completion of tasks based on the remaining story points. In Scrumban, for same-size tasks, it is worth filling the same value (e.g. “1 SP” or “10 SP”) in each item to create such a report:

Myth #4: There are no meetings

When you are working in Scrum, your agenda seems to be well-defined by its ceremonies. Planning, review, retro, daily, and refinement are timeboxed meetings that must be planned in advance and regularly repeated in each Sprint.

How about Scrumban? Can we get rid of meetings and focus on coding, finally?

Nope.

Scrumban also emphasizes the need for direct communication but does not define obligatory ceremonies. It is up to the Scrumban teams how and when they want to synchronize for the purposes of planning, collecting feedback and improving efficiency. Many Scrumban teams take advantage of Scrum ceremonies and their terminology but apply them in an “on demand” manner.

Pro-Tip

My Scrumban teams value Daily Scrumban (or Stand-up) as a time when they could do instant planning and ad hoc refinement. Sometimes the meetings extended the 15-min timebox but, as a result, we did not have to plan any extra meetings later in the day.

Myth #5: Scrumban is reserved only for maintenance development

Kanban and Scrumban are often connected with maintenance projects only. There is a common myth that you can switch from Scrum to Kanban or Scrumban only when your product is in the post-release phase. This is not the only case, however.

You can also consider switching to Scrumban if your team faces the following challenges:

• constantly changing priorities
• much add-on ad hoc work
• no Product Owner or/and many product decision-makers
• many rotations in the team or an unstable number of developers in the team
• same-length Sprints that do not overlap with releases

Maybe Kanban for Scrum Teams?

On a final note, before you start transforming your Scrum Team into a Scrumban one, it is worth checking out the option that scrum.org suggests in such cases: Kanban for Scrum Teams.

You do not have to make a revolutionary change, but introduce some (not necessarily all) kanban practices step by step, while at the same time leaving the Scrum framework as it is.

Summary

I hope you now know the answer to the question: What is Scrumban?

As we can see, there are many misconceptions around Scrumban. It is not a perfect framework, as neither Scrum or Kanban are.

When working on a product, it is always important to understand what goals we set and which framework will be best suited to achieve them.

My advice would be: start from the classics and then modify.

It is like learning how to play the piano: first you start with Vivaldi standards, and then you go for jazz improvisations – not the other way around. Start with what you and your team know best and then combine.

This evolutionary and empirical approach is what we practice at Droids On Roids. So far, it’s proving to work for us.

References

• medium.com/hive-blog
• agilealliance.org
• ntaskmanager.com

Related posts