Scrum vs. Kanban – How simple is that?

Marcin Niebudek

This one should be short… When I think about Scrum vs. Kanban question (which is coming back like a boomerang over and over again) I really have just one single distinction in mind – time boxing vs. flow.

If you think about Scrum and Kanban as a process frameworks (and I do so) then you can find more similarities. They both show you how to organize the work flow, give simple tools (backlogs, kanban boards). They focus on team collaboration aspect of the process. They give you simple visual indicators (burndown charts, cumulative flow charts) to quickly spot problems as well as simple metrics to give you the basis for planning (velocity, cycle time).

What is different is that Scrum creates fixed time spans and concentrate some activities around those time boxes boundaries (planning, demos, retrospectives) while Kanban goes for the continuous flow, which usually means that the mentioned earlier activities will blur a bit and change their character to more ad-hoc (instead of Scrum’s meeting oriented) style. So the question you need to answer is actually which type of work flow fits better your organization and the character of your project(s).

Do you prefer cycle with boundaries when you can for example reach your stakeholders every two weeks? Or maybe you need a freedom to make your code base unstable for let’s say 1 week and get it back to deployable state after a sprint without a pressure that this will affect some other features that need to be shipped in the meantime? Scrum might be better here.

On the other hand if you don’t need strict boundaries and you prefer to manage things in ad-hoc meetings. If you can ship features one by one or can work on them independently. If each of those features brings enough value to be shipped alone when it’s ready, then you may find Scrum too limiting and go for Kanban. Maybe you don’t have direct access to your users, your users prefer smaller increments wand want to get updates whenever they are ready. Go Kanban.

As always, you should probably be choosing the best of those two worlds. The important thing to remember is that the framework is not enough. You need to have a high quality engineering practices behind it. And those practices may be the same no matter if you choose Scrum or Kanban.  So don’t spend too much time on it.


  1. Peter Saddington -

    Good post. Sounds a lot like the client I’m working with now. We’re moving to a combo-scrumban of sorts and still working out how our client’s marketing department wants to have feature releases.
    Do like your point though, always good to remember that engineering practices behind the framework are crucial.
    Best to you!

  2. cuan -


    you dont seem to take into account the concept of work in progress ?

    Kanban can have timeboxes, it just does not mandate that you have…so not sure I agree with your post…sorry.



  3. Marcin Niebudek -

    @cuan actually I expected the the argument of timeboxes in Kanban. Sure you can have timeboxes in Kanban, as well as you can have WIP limits within Scrum sprints. Kanban uses WIP limits to control the flow while Scrum has its sprint capacities based on observed team velocity. These are mechanics for me, while the general focus of those two methods is set in different places.

    At the end I personally think a team ends with some hybrid as both frameworks contain very good concepts and actually I wouldn’t know how to call it and if it would more Scrum or more Kanban. So my point is rather in that the choice between Scrum and Kanban may be made in very general level, while in details it’s not so crucial.

  4. Alireza Haghighatkhah -

    Nice post, thanks for sharing.

    Scrum and kanaban are both type of agile methodology which help us to develop software in better way. but there are some difference between these two methodology. in my expirence scrum is ideal process management methodology for product development and in the other hand kanaban is derived from lean methodology with 50 years expirence in business industry. i think it’s no matter which agile methodology your are using, the important point is that we should adujst & mix different practices which is work for us. this is nature of agile “just enogh”. we can mix & match different practices from lean like brainstorming, 5 why and … into our scrum sprint planning & review meeting.

  5. Tobias Brandt -

    Is tinyPM going to support Kanban? it seems to me that the current task board already has most of the features. Perhaps a project level setting as Kanban which gives you an infinite duration iteration and a hard limit work in progress setting. Of course user stories would need to be removed when they’re done and you’d need a cumulative flow chart but that should be easy right? next you could allow for custom work flows but the basic version would already be very cool.

  6. Marcin Niebudek -

    We have plans to add features that would make using tinyPM a Kanban-way easier but this will probably happen closer to the end of the year. The nearest v2.4 will bring big changes in tinyPM’s wiki engine. After that we will probably be looking into Kanban features along with release planning stories as it will be touching same parts of tinyPM, but can’t promise right now. So stay tuned :-)

Leave a Reply