Why I Like Scrumban

Published on February 13, 2024, filed under Engineering Management (RSS feed for all categories).

Over the past years, I’ve become a fan of Scrumban, a mix of Scrum and Kanban. Together with the respective teams, I’ve used Scrumban at all my last stations—at Jimdo, at LivePerson, and at Miro, where I’ve inherited it.

Why do I like Scrumban—and what is Scrumban here, for me? Let me sketch this, and see how our experience compares.

Motivation for Scrumban

My motivation for Scrumban originated in two practical problems when using Scrum:

We’ve never had a single sprint goal.
We’ve always had to deal with side requests, from stakeholders not using Scrum.

There’s no single increment to be had in such a setting, and Scrum quickly gets awkward when you have anything from two to eight people working on anything from two to eight things. It gets just as awkward if your main partner is a hyper-growth Marketing team or an instability-plagued Engineering organization.

Cherishing Scrum

Now, before we move to Scrumban, allow me to cherish Scrum here. That we rarely get to see it fully practiced should not lead to discounting its value. Explaining this may require a post of its own; in all brevity, I believe the value of Scrum is best understood as a north star, as something to steer by.

When you read the Scrum Guide, you find much of use. I believe that what we could appreciate more is that every single element has a role and a purpose. That is, Scrum is not inflated (as SAFe may be), but contains what matters, and not more.

If you think about Scrum this way, you’ll notice how there’s benefit in not tossing out the entire methodology for two incompatibilities—and that it may be us, who bend Scrum this way, who may err, rather than that there’s something fundamentally wrong with Scrum.

Defining Scrumban

Roughly speaking, I connect the following with Scrumban:

Basing off of Scrum.
Using a Kanban work view of “to do,” “in progress,” “done” (or a variation that contains these statuses).
Dropping the idea of a sprint goal (or, as per the next point, of a single cycle or iteration goal).
Reframing a “sprint” as something like a “cycle,” so to have a check-in point to make use of Scrum events, but disassociate a little from the idea one was using “full” Scrum.
(Optionally, but something I’ve observed in enough cases to call out, dropping the sprint review. I still like the theory of reviews—but practice has often begged to differ with my likings.)

There is room for more views, there may be an “official” view that I’m not aware of, but that’s it from my view. “Scrum plus Kanban minus process incompatibilities,” that’s the summary I’d offer.

Using Scrumban

The devil, then, may be in the details—how to use this way of working.

In most of my own instances, tooling was based on Jira, specifically Jira’s Kanban board functionality.

Pretty often, there was no formal role of a scrum master. That often had me cover for this (with some background, that was fine with me), but in senior teams, team members have brought in ideas and took over responsibility, too.

Challenges have included wording (the term “sprint” comes with strong associations, hence the idea to reframe it as a “cycle”) and estimations (for which I have a nuanced view, best handled separately, but also appreciate more perspectives).

Here it fizzles out; for the moment, that’s everything that comes to my mind about using Scrumban.

❧ What are your views on the topic? Please comment here (if comments are still enabled) or, perhaps, on the toot for this post. Cheers!

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.