Why I Like Scrumban
Published on February 13, 2024, filed under 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
I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences. (Be critical, interpret charitably, and send feedback.)
Read More
Maybe of interest to you, too:
- Next: “Web Design as a Process” in Charts: Maintenance, Decay, Tech Debt, and Big Bang Launching
- Previous: Website Optimization Measures, Part XXII
- More under Management
- More from 2024
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.