97 responses on “One day in Kanban land

  1. Sorry – I laughed too much. Don’t be so funny if you got such an important message 😉

  2. Excellent!

    Can we see comparison (with a similar comic) “One Day in Agile Land” please?

  3. Is the change in dev limit from 2 to 3 intended to signify anything, other than the limits can change?

    I generally think that reducing the limits is a sign of improvement as the team achieves better flow

  4. Thanks for the presentation, it a great one !!! But it has left me confused on one point. I know Agile and I know scrum but Kanban is new to me. I dont understand when the presentation says Scrum team Kanban 1 and then says Kanban team 2 and kanban team 3 on slide no 10. Can some one please tell me wether scrum team are different than Kanban? Id yes whats the difference.

  5. If Team 1 calls themselves a Kanban team and Team 2 calls themselves a Scrum team, the only thing we know for sure is that they have different names. Other than that, the teams can be very similar or very different. I suggest you read the “Kanban vs Scrum” article, it should clarify things. http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

    The slides you saw are mostly just pictures, with little or no explanation.

  6. Have some of the slides disappeared? The Portuguese translation seems to have a few additional ones.

  7. Hi Henrik,
    This is great stuff. You’ve explained this as lucidly as one could get. Do you mind if I share this comic with my fellow developers?


  8. This really reminds me of a fast food restaurant. That’s a good thing. Deployment is king because in-progress or completed food that’s not deployed is going stale and the customers are going hungry. No point taking more orders or preparing more food if the orders aren’t being completed. The prime focus has to be deployment and staff get moved down-stream to relieve the blockage and balance the system.

  9. What a grap, no beef, no point, again new buzz word for obvious well known old stuff

  10. Thanks for the link and your comment about my design :).
    If others are interested I can give my images in SVG (inkscape) format.

  11. While introducing kanban, I showed this to them. They got the idea very quickly and enjoyed it. Thank you for great work 🙂

    (I’m one of the Korean translators of your Scrum and XP Book)

  12. I have also a demonstration of Kanban coming and these I was planning to show as well. I’ve worked with Scrum and Kanban now for a year and eventually starting to get the big picture 🙂 Your work has both helped and inspired me a lot and for that I salute you sir. Tack så mycket.

  13. Bastante bueno el comic. Gracias por ponerlo, así uno conoce más sobre Kanban.




  14. This is great, of course, AND this is how I have always coached people to do Scrum. Work on one story at a time (max two) and the whole team work on outstanding tasks for that story until the story is complete. I can’t imagine why anyone would do otherwise. It would result in a loss of focus and a task-switching overhead.

  15. In a Scrum sprint, would you be OK with not having a sprint plan, and instead having the PO add stories to the sprint on a just-in-time basis? That particular aspect is otherwise what I consider to be non-Scrum. Scrum, as I’ve understood it, prescribes that the team should commit to a fixed number of stories for a sprint, and not allow the PO (or anyone else) to change this during the sprint.

  16. Thanks a lot for sharing the article on google. That’s a awesome article. I enjoyed the article a lot while reading. Thanks for sharing such a wonderful article.

    1. Dear Henrik,
      You’ve done a great job! unfortunately the page in persian does not exist any more! Is it possible to have it in persian ?
      Or with more explanation in english beside the Pictures? that would be great 🙂
      Thank you

  17. Thnaks Henrik, your comic is great to explain Kanban to others!
    Just note that the link to the french translation is broken …

  18. 🙂 Great Stuff!!

    Last slide was funniest when KANBAN limit exceeds to 3… LOL!

  19. Put some keywords dude, Its really hard to find this post trough google search engine

  20. Pingback: Quora
  21. First off, the cartoon is really meant to illustrate a high level interpretation of the Kanban objectives.

    This cartoon is pretty typical of the early development effort of many teams. Though I see only minor problems, I think there is a great opportunity for deploying best practices.

    1. The development team hadn’t agreed on development standards. As a result, someone broke the build.
    2. Increasing the development Work-in-Process (WIP) limit from 2 t o3 (see last box)…
    a. Hides problems or constraints in the process, in this case a broken build or deployment process. The Team (capital T) has the impression that work gets done since after all more stories are being developed, but no value is being delivered since that only happens when a story is deployed.
    b. Adds little value early on at least because the Team (capital T) can’t even consume the first story or unit of work.
    c. However, it is reasonable to increase the WIP limit once the Team (capital T) can demonstrate that it is able to consume the
    3. Everyone rushing to offer help increases disruptions and puts additional pressure on the team when those involve know what needs to be done

    1. Implement a Sprint 0 so that the Team (capital T) can iron out bugs in the end-to-end process.
    2. Implement development standards to reduce the possibility of new checked in code breaking the build.
    3. Implement ‘Continuous Integration’ to identify immediately when a unit of code breaks the build process.
    4. Implement an automated ‘Smoke Testing’ or ‘Regression Testing’ process to make sure that the none of the existing functionality is broken in the latest build. After all, why deploy a new build that takes a step backward in quality and functionality delivered?
    5. The Team (capital T), but usually the ScrumMaster in Agile, could have better communicated its problems and delays, in particular to the Product Owner (red figure) to better manage expectations

  22. Never read something that clear. Heads up for explaining a not-so-simple concept, its advantages / disavantages without any tech word and in a 5 minute easy-and-fun-to-read comic.

    Congrats and thanks

  23. Hi Henrik,

    You’ve done a great job.
    It’s the most easy-to-understand way of describing Kaban.
    May I share your brilliant work on my blog and leave a reference back to your blog?

  24. Hi

    Very nicely illustrated . Can I use this in my Kanban presentation? I will mention this article to be the source.


  25. Hey, I stumbled upon this while going through this.
    Kudos to you for making such a simple and well illustrated doc to explain the working. I’m very new to working with agile methodologies and this presentation really help me to get my basics about the kanban right.

    However, I’ve a question. I see task A is deployed after it was done and in the deployment stage we figured out “A” isn’t building?

    Did B, C, D that appear in the live column in the last slide, did they also go through the deployment stage?

    And does “deploy” stage here mean, external testing by the potential customers?

  26. Hello Henrik,
    Is the One Day in Kanban Land comic illustration free to use in a corporate setting with proper attribution?

  27. Hi!

    It seems the green team members on the deploy stage is waiting for something to deploy.
    I assume they have other development/operations tasks while waiting for something to deploy?
    And they are part of the team?


  28. This is completely awesome and I love it… now to make it work in the real world! 🙂

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.