Gosia Podzorska on episode 34 of Appfire Presents: The BEST Project Portfolio Management Show by Appfire

“What’s the difference between Scrumban and Kanban?” Find out in this episode of Appfire Presents: The Best Project Portfolio Management Show by Appfire.

Appfire’s own Gosia Podzorska joins Kerry O’Shea Gorgone to explain Scrumban vs. Kanban: The differences and similarities, when to use Scrumban, and the benefits of that approach.

To dig deeper into this topic, check out this article on Whiteboards.io.

About the guest

Gosia Podzorska is Content and Communication Specialist at Appfire. 

About the show

The BEST Project Portfolio Management Show by Appfire covers everything you ever wanted to know about PPM by talking with project management experts who’ve seen it all. And every episode is 10 minutes or less, so you can get back to changing the world, one project at a time.


For your convenience, here is the transcript of this episode:

What’s the difference between Scrumban and Kanban?

Kerry:  Today we’re going to tackle the question what is the difference between Scrumban and Kanban. I feel like I’ve said it wrong my whole life, so that’s the first question we’ll get answered. To help us answer that question is Gosia Podzorska, content and communications specialist at Appfire. Stick around for 10 minutes of project management awesome.

Gosia, I always say Kanban, but maybe that’s pretentious. What even is it, how do I say it?

Gosia:  It’s Kanban and Scrumban.

Kerry:  Cool. So, now what’s the difference?

Gosia:  Before we jump to the difference, maybe I’ll just explain what Scrumban is. Scrumban is agile development methodology. It’s basically a Scrum and Kanban hybrid. It was invented by Corey Ladas because he found some shortcomings with Scrum. He released a book called Scrumban: Essays on Kanban Systems for Lean Software Development.

Kerry:  So, you put the two together kind of?

Gosia:  Yes, exactly. It’s kind of taking principles from Scrum and principles from Kanban, so Scrumban is kind of in the middle. 

The main characteristic of Scrumban is that there are no strict roles. In Scrum, we have product owner or scrum master. The other characteristic is that the main focus is on optimizing the speed to market.

Kerry:  Okay. That’s the difference then is who it would be good for and how much information it gives you about how to do the things. I feel like one is principles, is what it seems like, and the other one is an actual methodology.

Gosia:  Actually, both of them are methodologies. We can’t say that they are frameworks. Scrum is a framework, and Scrumban and Kanban are methodologies. Both of them are based on principles. There are loads of similarities, but also some differences. 

Do you want me to go into similarities of what is similar between Scrumban and Kanban? 

Kerry:  I do, because I don’t know any of this. 

Gosia:  Basically, one of the similarities is that tasks are visualized on a board, so it’s much more transparent for the team and for the stakeholders what is the current progress of the tasks. 

Another similarity is that Scrumban and Kanban are based on a pull system. What is a pull system? It’s actually when each individual team member pulls a task and starts working on it, instead of the task being pushed by the project manager and assigning the task to a specific team member. That’s another of the similarities.

One more similarity is the work in progress limit. The work in progress limit is applied, let’s say the team decides each team member can work on a maximum of two tasks at the same time, and they have to finish one of the tasks before pulling another task.

Kerry:  That seems sensible, based on what we know about task switching and how people become a lot less efficient. 

Gosia:  Exactly.

Kerry:  You don’t want to have eight things on your desk.

Gosia:  Yes. I think it’s so easy to start something but not really finish, and then you start another thing. Without work in progress limits, we end up with lots of tasks started, but maybe not a lot of the features released. 

These are the similarities, but there are also differences. What’s the main difference? In Scrumban, actually, it’s time based work. In Scrumban, teams are not working in sprints like in Scrum with two-week or one-month sprints. The tasks are organized into one-year, six-month, and three-month buckets. The one-year bucket is for the long term goals, six-month bucket is for specific goals, and the three-month bucket is actually for tasks that have clearly defined requirements. The Scrumban team pulls the task only from the three-month bucket. 

In Kanban, we don’t have that. In Kanban, it’s kind of like one large continuous workflow. We don’t have the buckets.

Kerry:  The time thing. You could be working on a year or an 18-month-long project.

Gosia:  Exactly. In Kanban, it’s less structured. There is much more gray area. It’s actually more suited to more advanced agile teams. Scrumban is good for maybe teams that are just starting out and trying to transition to agile because they’re more structured, but it’s not as rigid as Scrum, so it’s a bit easier to implement.

Kerry:  That’s when you would use Scrumban then is when you have a newer team or a team with newer members.

Gosia:  Yes. It could be actually in startups. In a startup environment, especially if you don’t have a lot of budget and you can’t factor in new roles like product owner or scrum master, you can start with Scrumban. 

Also, let’s say you’ve identified an issue that there is a slow speed to market, like your team is not producing features as fast as the management wants and you would like to optimize that, you can try Scrumban. In Scrumban, you don’t have to stick to the really rigid agile that you have in Scrum. You don’t even have to do estimation sessions, you don’t have to do daily scrums. You can, but you don’t have to, or you can do them less frequently.

For example, retrospectives. We would still recommend teams to go through retrospectives, but you can have them less frequently. Let’s say after every five features released. In Kanban, you don’t have any agile events at all, so Kanban is less structured.

Kerry:  Are there types of projects that work better with Scrumban versus Kanban? I can’t even say it the different way, I keep saying it wrong.

Gosia:  That’s okay. Yes, actually, Scrumban is better for larger projects. Well, it’s good for small and large projects, and it’s good for cross-team collaboration. Kanban might not be as efficient because of the more linear continuous workflow. You don’t have those on-demand planning sessions and prioritization, so there is less communication with different teams. 

If you’re working with different teams and you’re waiting for their input, if you’re working in Kanban, you might end up with those bottlenecks and blockers. Kanban is actually good for teams that have repetitive tasks and they don’t depend on input from others.

Kerry:  Whereas Scrumban would be more for like you’re doing something new? 

Gosia:  Yes. Scrumban is good for larger projects and also if you’re working on different products, for example. Kanban would be better if you’re working on one product.

Kerry:  Which do you think is easier to pick up for a team? Like at a startup where they’ve just assembled their team and now they have a bunch of stuff to do, which one do you think would be better for them?

Gosia:  I think Scrumban would be better because it has a structure. For some teams, if they are working in Kanban, they might feel like there’s too much gray area and it’s open for interpretation. That’s why Kanban is better for advanced teams. Advanced teams in agile can kind of embrace that, not a lot of structure. 

I would say for teams that want to just try it out, I would recommend Scrumban. If they feel that they are okay with less structure, if they feel that there’s not a lot of direct pressure from management, there are no strict deadlines, then they could try with Kanban.

But I would say the best would be probably to just sit with your team, look at the problems that the team has, is it the code quality, is it the speed to market, and then optimize. Try Scrumban and see if the speed to market increases. They can even try Kanban for a specific time period and just see which one performs better in the team, because each team is different.

Kerry:  There’s not many teams that people are like do whatever you want and we’ll get it when you’re done, whenever that is, it’s fine. Most of them do have a backlog, even by the time they start, of stuff that has to get done quickly.

Gosia:  That’s true. Some teams might have a lot more pressure, especially in larger organizations. I guess in startups there might be less stakeholders involved, it’s just the pressure is different. In larger organizations, maybe it’s much more structured, so the deadlines are stricter.

Kerry:  Where can people learn more about Scrumban and Kanban if they want? I know I’m still saying it wrong. 

Gosia:  Actually, we have a blog post they can go to and the differences are explained. There’s even different steps that the teams can take to go from Scrum to Scrumban if they want to try it.

Kerry:  Perfect. I will put the link to that article in the description below this episode. Thanks so much for joining, Gosia. Thank you. This has been The Best Project Portfolio Management Show by Appfire. You can find more episodes at Hub.Appfire.com. We’ll see you next time.

Last updated: 2022-09-30

Recent resources

Back to Top