Kanban vs Scrum

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Kanban

There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some of the fog.

  • Jim: “Now we’ve finally gone all-out Scrum!”
  • Fred: “ So how’s it going?”
  • Jim:  “Well, it’s a lot better than what we had before…”
  • Fred: “…but?”
  • Jim: “… but you see we are a support & maintainance team.”
  • Fred: “yes, and?”
  • Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc….”
  • Fred: “So what’s the problem?”
  • Jim: “We keep failing our sprints”
  • Fred: “Why?”
  • Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?
  • Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
  • Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints…”
  • Fred: “Do your issues take less than a day to fix?”
  • Jim: “No, they sometimes take several days”
  • Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
  • Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
  • Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
  • Jim: “So what should we do then?”
  • Fred: “Have you heard of Kanban?”
  • Jim: “What’s that? What’s the difference between that and Scrum?”
  • Fred: “Here, read this article!”
  • Jim: “But I really like the rest of Scrum though, do I have to switch now?”
  • Fred: “No, you can combine the techniques!”
  • Jim: “What? How?”
  • Fred: “Just read it…”

Kanban vs Scrum – a practical guide

This is a draft – any feedback is welcome! For minor corrections email is probably best (henrik.kniberg AT crisp.se).


By the way, on May 27 we’ll be teaching a one day course called "Future of Agile" together with David Anderson, one of the early pioneers of Kanban-style software development. If you’re interested in this stuff I suggest you join us!

55 Comments

  • 1
    Manuel Kueblboeck
    2009-04-04 - 08:30 | Permalink

    Thanks for sharing Henrik. Great article as always. I am/was new to Kanban and this article positions it in easy terms in comparison to Scrum.

    Just one thing I noticed in section 5: “A team that has an average velocity of 10 will usually not pull in more than 10 items to a sprint.” Shouldn’t it be “…not pull in more items worth more than 10 story points”?

  • 2
    2009-04-05 - 06:53 | Permalink

    Thanks, I’ll correct that!

  • 3
    2009-04-07 - 01:53 | Permalink

    A very welcome contribution, great job!

  • 4
    david prince
    2009-04-07 - 02:02 | Permalink

    Hi Henrik,
    Great job…as usual;) Thank you for this guideline …

    A question from reading page 25:
    How to use “Lead time as primary metric for planning” IF “No particular item size is prescribed”?
    It is still not clear for me :/

    Kanban works well @ production when tasks are standardized (like drill a hole in a piece) and the same size.

    If tasks sizes have too much differences nothing would be predictable ???

    BR,

    David

  • 5
    2009-04-07 - 03:05 | Permalink

    Great contribution Henrik 🙂

    I will be sending some comments via email based on my experience.

    For the time being you could check out how we have applied Kanban in our internal development.
    Hopefully having soon time to blog also how we have applied Kanban to sort out “shared resources” in few of my customer cases.

  • 6
    2009-04-07 - 06:17 | Permalink

    Hi Marko, thanks for contributing your case, that was an interesting read!

  • 7
    2009-04-07 - 07:36 | Permalink

    Your example is good. A support/maintenance situation is an ideal fit for kanban.

  • 8
    Tim Elton
    2009-04-07 - 09:28 | Permalink

    You CAN add additional stories during a Sprint, but you have to get the originally planned stories done first. In a case such as this, you would also take care to ensure that the added story could get done by the end of the Sprint.

  • 9
    2009-04-08 - 06:36 | Permalink

    Good point Tim, I’ll update the article. Thanks.

  • 10
    2009-04-08 - 09:41 | Permalink

    Hi Henrik. I really like this article. I made some comments on my blog for the bits I don’t agree 100% on: http://kanbanjedi.wordpress.com/

    Maybe this is a good set of topics for discussion on the Kanban mailing list: http://groups.yahoo.com/group/kanbandev/

  • 11
    2009-04-08 - 06:39 | Permalink

    Thanks for the feedback. Good idea to bring the discussion to the Kanban list, will do that.

  • 12
    Erik Bos
    2009-04-08 - 08:33 | Permalink

    Hi Henrik,

    thanks for the article. Exactly on time for me, since I want to start using kanban for some teams. I’m still confused about sizing the buffers; I can imagine limiting the items under work, but how to limit the buffers???

    Cheers,
    Erik,
    Eindhoven, NL

  • 13
    2009-04-10 - 02:20 | Permalink

    Make the buffer/queue visible by having a column for it. Make up a suitable limit (for example 3) and write it at the top of the column. To be even more clear you can draw 3 rectangles in that column as well. Then simply enforce the rule and experiment until you find the right limit that gives you the smoothest flow.

  • 14
    Rafael E. Santos
    2009-04-09 - 08:39 | Permalink

    Hi Henrik,

    Great article. I was looking for something to shared with my collegues and employees that explains Kanban and your article is perfect. We have been doing Scrum for 4 years, so it will be very easy for everyone to understand Kanban by looking at how it compares with Scrum.

  • 15
    Jeroen Knoops
    2009-04-10 - 08:50 | Permalink

    Henrik, thanks for this article. Currently we are trying the first ‘sprint’ of Kanban and this article couldn’t come at a better time!
    I’m glad that you’re explaining how things can be combined. Scrum practices and Kanban practices. Now it’s not only me how telling it to our management, but also Henrik! 🙂

  • 16
    2009-04-10 - 03:14 | Permalink

    Uh oh, does that mean they’ll blame me if it doesn’t work? :o)

  • 17
    G. H. Chinoy
    2009-04-10 - 10:08 | Permalink

    Another great article, Henrik! I particularly like how this can be applied to scrum to kanban transitions for projects that can benefit from lean/kanban. Thank you!

  • 18
    Rex Card
    2009-04-11 - 03:52 | Permalink

    Good post. Your “Scrum from the Trenches” has had a positive effect on our development teams. Looking to work in some of the Kanban principles and want to thank you for your work.

  • 19
    Mike Sutton
    2009-04-11 - 12:26 | Permalink

    Love the article , will send more editorial comments on another pass.

    I wanted to share this…

    I have a team that is doing kanban with their Scrum – I was inspired by a chat we had (Henrik and I) on the way to/from the Stockholm gathering.

    The WIP limit issue is something I’ve seen that is actually a result of self organising and happens dynamically.

    The team start off by swarming round a story and determine how many people is not a crowd. Everyone else then moves on to the next story. So their WIP limit may have started as 1, but it just changed.

    If the WIP limit is subject to dynamic change, is it a dependable measure?

    Also , in my limited experience.. communicating the WIP limit outside the team fueled command and control freaks who say ‘7 people on one story at time – that can’t be right’. You should have ‘2 working on this, 3 on that and …’

    I’m not saying hide it, I’m saying be careful about becoming prescriptive.

  • 20
    Uday Bhobe
    2009-04-13 - 03:18 | Permalink

    Excellent article. Really helpful. Thanks a ton.

  • 21
    2009-04-15 - 09:50 | Permalink

    I’ve read the whole article in a flash. It’s incredibly clear, simple and focused. Great Job. Thanks a lot for sharing.

    Alberto

  • 22
    Tim Uttormark
    2009-04-16 - 04:56 | Permalink

    Another distinction is that Scrum teams commit to delivering the stories in each iteration, but that commitment can be invalidated if the membership or availability of team members changes during the iteration. Kanban on the other hand is much more accommodating of changes in the team composition at any time.

    This line of thought could be expanded to include a categorization of projects for which each technique is a good fit. For example, the sweet spot for Scrum is when your project is like A, B, or C; but Kanban tends to be a good choice when your project is like X, Y, or Z. The dimensions of distinctions might be things like maturity of the team in agile and lean, technical competence of team members, availability of team members to work with the team, sizes of work items (do they tend to be about the same size or vastly different), and the amount of interruptions that the team experiences (for high priority work which must take precedence over planned work items).

  • 23
    2009-05-14 - 01:39 | Permalink

    Good points, Tim. Thanks! Might add something about the team composition issue to the article.

  • 24
    2009-04-23 - 10:45 | Permalink

    I’ve just finished reading the paper. I think it’s great. I’d like to thank you for sharing it.

  • 25
    Fabrice AIMETTI
    2009-04-26 - 11:05 | Permalink

    Hi ! Very good article ! I have translated the whole article in french. You can download it on the following link : Kanban-vs-Scrum-French.pdf

  • 26
    2009-04-27 - 09:49 | Permalink

    Great work Fabrice!

  • 27
    2009-05-13 - 07:35 | Permalink

    At PatientKeeper the number of Sprints was controlled (WIP number). All Sprints go to production when done and may be of different lengths. So every Sprint is a Release. There is one Scrum board used by all teams and all Sprints are on it. Any team member from any team can reassign any story to any other team for any Sprint. Work self-organizes so all Sprints complete on time (0 work in progress at end of Sprint) almost all the time. 45 releases a year were deployed to large enterprises.

    Ken Schwaber called this a competitive monster. Tom Poppendieck called it a business process innovation. Maybe it is Scrum-Ban on steroids. What would you call it?

  • 28
    2009-05-14 - 01:37 | Permalink

    Hmmmmm. Maybe SDOS (software development on steriods) or maybe PCP ( pretty cool process)? :o)

    Sounds like your PatientKeeper implementation would be a fun point to bring up at Deep Lean next week!

  • 29
    2009-05-15 - 04:09 | Permalink

    So all future features are sitting in the backlog. Does Scrum or Kanban allow for planning ahead or does everything go in the backlog until a sprint/iteration is planned?

  • 30
    2009-05-15 - 03:04 | Permalink

    Seems to me that kanban is ideal for teams who aren’t disciplined enough to stick to agile (scrum) practices. Seems like it’s too easy to switch priorities and with the wrong stakeholders involved in a project – that can spell disaster. Not that switching priorities isn’t sometimes necessary but scrum provides a way to accomodate this. Remember, there are only a handful of principles that govern the scrum agenda – http://www.agilemanifesto.org – the rest is just an extension for that.

  • 31
    2009-05-15 - 03:16 | Permalink

    I don’t think the amount of discipline required has anything to do with whether you are using Kanban or Scrum or a combination of the two. More rules doesn’t automatically mean more discipline is required.

    Neither Scrum or Kanban will help very much if your team lacks the discipline to follow rules that they have agreed to.

  • 32
    Ben Levy
    2009-05-15 - 04:17 | Permalink

    Really enjoyed the article as I hadn’t read much about Kanban up until now.

    We have been using Pivotal Tracker as a tool to assist our process. The tool has helped us become more “scrumish” introducing some “kanbanish” ideas to us (and we didn’t even know that’s what they were!) Before we used it our sprint planning took longer – prioritising and calculating what we would include in the sprint carried more overhead. We also were more concerned if anyone wanted to change things mid-sprint. Now unless something has been started (or has dependencies) it can be re-prioritised. Moving something into the current iteration forces something else out. It feels agile.

    We use the timeboxed sprints still though as they provide our velocity (we always have deadlines and time commitments so this seems the most straightforward for us at the moment). However, on our projects where we have sprints of 1 week we are using the end of a sprint as an indication that a retrospective may be relevant. Sometimes it feels better to skip a week to judge how things are going (eg: to be able to tell if we’ve improved something or not).

  • 33
    2009-05-15 - 05:58 | Permalink

    Hi Ben, thanks for the info!

  • 34
    2009-09-15 - 12:57 | Permalink

    Great description, Henrik. Thanks for writing it.

    By the way, I can’t see all of the “meter” image on page 15, only the first half and last fourth.

  • 35
    Beth
    2009-11-19 - 04:58 | Permalink

    Henrik, in your prescriptive/adaptive discussion, you say that Scrum has 9 “rules”. Which 9 are you referring to? I know what the 13 practices of XP are and the 3 principles of Kanban, but I can’t come up with 9 rules for Scrum. Thanks.

  • 36
    2009-11-19 - 07:11 | Permalink

    3 roles (product owner, scrum master, team). 3 artifacts (product backlog, sprint backlog, sprint burndown), 4 activities (sprint planning, daily scrum, sprint review, sprint retrospective). OK, so 10 then, guess I should update my slide :o)

  • 37
    2010-02-24 - 09:15 | Permalink

    Hi Henrik,

    I have referenced this post in an article I just published, from Scrum to Kanban.

    This is a great post and thanks for sharing.

  • 38
    2010-02-25 - 07:39 | Permalink

    Great article, thanks for sharing!

  • 39
    Gulin
    2010-08-26 - 02:15 | Permalink

    Thank you for this article…
    It is very usefull for the beginers of Kanban

  • 40
    Kevin
    2010-09-24 - 05:53 | Permalink

    We are currently starting to use Kanban in a project for support tasks.
    I have a question to see what would be the best option for this scenario:

    We have a story which analysis has been completed, so we moved it from ‘Analysis Pipeline’ to next state ‘Development Buffer’.

    Then the Product Owner realized that some definitions were missed, so.. should the story be moved back to ‘Analysis Pipeline’?

    We have a property which is ‘Analysis Completed On’ (that we use for metrics.. to calculate the time stories spend ‘In Analysis’), that would be reset. Is that ok? Or should we not move the story back to ‘Analysis Pipeline’ and complete those pending definitions leaving the story where it is.. in ‘Development Buffer’ state?

  • 41
    2011-01-07 - 05:46 | Permalink

    Moving from Scrum to Kanban because Scrum imposes constraints that are hard to follow is a false step.
    Part of the *point* of Kanban is to impose constraints that are hard to work with.

    That difficulty is deliberate, and is there to highlight inefficiencies in your process. So you find the inefficiency and fix it. And then tighten the constraints again, to give yourself more pain, and identify more inefficiencies. And fix. And repeat.

  • 42
    2011-01-09 - 05:36 | Permalink

    Jepp. The value in a tool is in how it constrains you. Scrum and Kanban contrain in different ways (sprints in Scrum, WIP limits in Kanban). Constraints are needed to generate focus. If you remove all constraints then you are really just using the do-whatever process (which may be fine for a small team doing trivial repetitive stuff).

  • 43
    Raj Iyer
    2011-09-29 - 05:16 | Permalink

    Hi Henrik,

    Great article and comparison. Do you have any comparison with Six Sigma? If an organization is using Scrum and looking at Kanban, how does Six Sigma fit into this? Should the organization dump Six Sigma and just adopt Kanban or do they go hand-in-hand. If you haven’t done such analysis, do you know if anyone has published anything around that?

  • 44
    2012-03-11 - 23:53 | Permalink

    Nice write-up.

    Some more related reflections on Kanban vs. Scrum are here:
    http://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/

  • 45
    2012-03-21 - 11:53 | Permalink

    […] are different opinions about the minimum number of rules scrum requires. The minimum set of rules to my understanding […]

  • 46
    2012-03-28 - 11:17 | Permalink

    I recently posted a blog summarising a conversation that I initiated on twitter asking people to define the difference between Kanban and Scrum in 1 word – it’s here and might be of interest to readers of this blog.

    Enjoy.

  • 47
    2012-06-25 - 09:03 | Permalink

    […] According to Henrik Kniberg, “Kanban is an agile development methodology that aims to assist you in visualizing the workflow, limiting the work in progress and measuring lead time for your projects.” […]

  • 48
    2012-07-12 - 21:40 | Permalink

    […] more than a todo list (that guy’s paper is like a thesis) requires an in-house guru with lots of […]

  • 49
    2012-10-17 - 18:55 | Permalink

    We build a kanban simulator in which you can see what a WIP limit does for your flow. You can see how it works and where you can get the source here: http://blog.zilverline.com/2012/09/21/flowmulator-a-kanban-flow-simulator/

  • 50
    2012-11-21 - 17:22 | Permalink

    […] to sprints isn’t going to happen – one good example of this is operational or production support models, instead of new development projects. That being said, think about the production support […]

  • 51
    2013-08-16 - 14:14 | Permalink

    […] 2009 Henrik Kniberg ao escrever um artigo no seu blog sobre Scrum e Kanban nunca pensou que iria cunhar um conceito (na minha opinião) […]

  • 52
    2014-01-23 - 02:00 | Permalink

    […] qualquer trabalho que estiver em progresso via linhas de prioridade/escalonamento. E as prioridades podem continuar mudando até o último minuto – membros do time simplesmente pegam o item que tem a maior prioridade da […]

  • 53
    2015-02-17 - 17:31 | Permalink

    Hi Henrik,

    My name is Fernando, I’m from Santiago of Chile.
    I belong to the company Mainsoft, and we are applying Scrum in Telefónica.
    I’m reading your article “Scrum and XP from the Trenches”, which is entertaining me.
    In Chile, where I can take the course of ScrumMaster?.

    My email is fcarvajal@mainsoft.cl for direct communication, which I appreciate.
    sorry for my english. i.e., english of google.

    regards,
    Fernando.

  • 54
    2015-09-25 - 17:25 | Permalink

    Just so it gives another perspective: http://izlooite.blogspot.ae/2010/09/kanban-vs-scrum.html

  • 55
    2015-10-15 - 21:20 | Permalink

    […] qualquer trabalho que estiver em progresso via linhas de prioridade/escalonamento. E as prioridades podem continuar mudando até o último minuto – membros do time simplesmente pegam o item que tem a maior prioridade da […]

  • Leave a Reply

    Your email address will not be published. Required fields are marked *