Kanbanboards

  • 62,413 views
Uploaded on

These slides are some examples on how to use and create a workable Kanbanboard. …

These slides are some examples on how to use and create a workable Kanbanboard.

We have used some kind of stop-motion-animation and the intent is that you should move through the slides fairly quickly for best effect.

Read more on http://www.marcusoft.net/2010/03/practical-kanban-some-kanban-boards-in.html

Me and Joakim Sundén has now written a book on kanban (http://bit.ly/theKanbanBook). The book is similar to this presentation in that it's very pragmatical and practical. I hope you like it.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Hi Marco, sorry I'm this late, don't read this much. We often use a magnet to attach both the avatar and the card.

    I've also seen people use magnetic strips of tape on the flipside of the avatar.

    And other still doesn't use avatar but their signature on the work item card.

    Hope you can find something that suits your need among these suggestion.

    Thank you for reading our book. Get one for yourself! It is good to have next to your board
    Are you sure you want to
    Your message goes here
  • I've borrowed your book from a friend and reading right now. Great! Just one stupid/funny question: how to attach the avatars to the board? Sticky notes are clear for the tasks... should I draw avatars on sticky notes as well? If so, they'll have a very small glued area and probably won't stay put... :)
    Are you sure you want to
    Your message goes here
  • Thanks Tim. New book based on this presentation (and more) is coming nov-13. http://bit.ly/theKanbanBook
    Are you sure you want to
    Your message goes here
  • Seeing is believing. Not technoidal, I needed that!
    Are you sure you want to
    Your message goes here
  • Great introduction to Kanban. Thanks guys for sharing it! This has inspired me and I wrote these slides - http://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
62,413
On Slideshare
0
From Embeds
0
Number of Embeds
50

Actions

Shares
Downloads
1,068
Comments
36
Likes
223

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • This presentation will show how to adapt Kanban in your development project.

    There are quite a lot of slides and quite little text on each slide and the whole idea is that you should go through the slides quickly and a little animation effect will take place.

  • One of the good things of Kanban is that it’s a evolution, not a revolution. You can adapt Kanban step by step.

    Start from your current Scrum board and enchance it to reflect your process.

    Actually - it will be many slides down before we will doing something that not fit inside Scrum.
  • So a good starting point could be to visualize your workflow. If you are working with Scrum you are doing that already.

    But maybe it could be a little more crisp than Todo, Doing and Done
  • Make some place for some more columns

  • and move the “Done” items to that column
  • Often you start by analyzing a story, so lets a put a column to represent that work.

    - what’s included
    - how should it be solved
    - break down into task
    - etc.

  • And then we’ll add a column for the development of the story

  • And finally we need to verify and test the feature so that we are sure that the quality is good enough for our team to release.

  • One way of handling handoffs between specialists is to introduce queues so that work is buffered. In this way the next step can see when things are ready to be pulled from the Done-queue of the previous step.

    It doesn’t have to be hard specilization - even if it’s roughly the same people doing the work this can be useful to visualize the flow. So that we can where blockage, uneveness and other problems occur.

  • Let’s add a done-queue for development, to give a signal to Test when new work is ready to pull.

    In this case we added the Done-queue in the Development-step. You could also argue that it should be in the Test-step and be called “Ready for test” or something.

  • We now have our (simplified) work flow setup. Now it’s time to decided how to limit how much work we will allow to be in progress at one time - to Limit our WIP.

    There are some different approaches to come up with the total number for that:
    - 2 per person, so that you don’t get blocked. A bit less maybe. We don’t want everyone to be blocked
    - Equal to the number of persons in the team
    - The number of persons divided by 2 for experienced agile teams
    - Start from the bottleneck, the number of tester for example

    - Any number! We will change it as we see problems and opportunities.

  • Limit Work in progress for all columns or some, at least “Doing”

    We have limit Work in progress for Analyze to 2, Development to 3 and Test to 2 features at the same time.

    We have no limit for our backlog, Todo - but you very well could, to limit the flow into the system.
  • We will now quickly demonstrate a normal flow on a Kanban board.
  • Here’s the intial stage...

  • Work is pulled from the backlog into the Analyze column as the WIP-limit allow.

  • You could wonder what Dev and Test is doing in these early stages of the flow...

    Well, the start will get a bit bumpy since no work are ready to be pulled. But this is for the very first time only, since a Kanban board never will be reset. In Scrum, for example, this situation is likely to occur in each sprint.

  • As work progress you monitor the flow of items.
  • Follow the WIP limits and only pull new work to your capacity



  • As we can see...
  • ... work is flowing along nicely since...

  • ... each step is only pulling work when it’s done ...

  • ... and not over their capacity.


  • Tam-tam-tam - working with Kanban is a breeze!





  • We’ve started work on the last feature in our backlog.
  • About the same time as the first feature is ready to be launched!

    Yeah! Champagne to all!





  • And we’ve pulled the last feature into development.




  • Now the development of the last feature is done and we’re ready to do the last bit of testing
  • The testers are working along to bring our goodness to the customers.
  • Closing in on the last feature.

  • And we’re done!

  • That wasn’t to educating since everything went well. It was good - but not educating...

    How do we handle problems? Let’s reset the board to a problem situation and find out.
  • Here all columns are fully loaded. Test is up to their limit and Development is finishing off the last story.


  • Actually, the Development team want to pull some new work. They are sitting idle...
  • But we cannot allow that - that would break their Work in progress limit off 3, now wouldn’t it?





  • So here we have a bottleneck in the Test-step. We want to move things along, but since Test are up to their WIP-limit we cannot.

    What’s good is that queues like this doesn’t happen instantly. You can see it build up and you can react to prevent it. The queue is a “leading indicator”. Compare that with burndown in Scrum which is an example of an trailing indicator that gives you the figures on how thing went.

    What to do? Theory of Constraints gives some options:
    - Exploit the bottleneck so that it’s used to the maximum, for example remove other work from them so that they are only doing testing
    - Elevate the bottleneck by increasing the capacity, for example employee more testers

  • Another thing to look out for is starvation.
  • This situation gives us empty columns or starvation.


  • The analyze don’t have anything done and Development is idle with no more work to pull.


  • This of course not good either but is another leading indicator. You can see when it’s about to happen and maybe react early, rather than face the figures afterwards.
  • That was some example of the flow of work on a Kanban board.

    But how do I draw new work? What are the strategies and rule I need to adhere to?

  • Here is Joakim - the tester - ready to complete the feature is testing right now.
  • Yes! It’s done!

  • What should he chose now?
  • Since there are work in progress in his column - the testing Marcus is doing - he should first and foremost see if he can help to finnish the work that is in progress.

    That’s our main goal - to finnish work in progress.

  • So Joakim and Marcus will test that feature together
  • They start to test it...
  • ...and before long...
  • ... that feature is also Done!
  • What now? Both Joakim and Marcus is ready for some more work. Nothing to finnish in their column.
  • But there are new work to be pulled from the Done-queue of the Development team.
  • Great! They draw new work...
  • Each starting a feature - to get work to be done as quickly as possible.
  • Another way to handling the siutation...
  • would be that they could work together...
  • ... on the highest prioritized item...

  • ... to quickly get that item done.
  • Look - they are on their way to be done
  • Well - that was quick! Great work guys!
  • Here is a case where Marcus, the tester is left with no work in his column AND no new work to draw.

    What should he do now?
  • Mikaela apparently wants some help, to get the item she’s working on ready for test...


  • But that is sadly not possible since Marcus is no programmer.


  • But... we have a bottleneck in Analyze. They are fully loaded and no new work is flowing from them.

    Both Joakim and Black-And-White-Marcus is working. Could Full-Color-Marcus possibly help over there?

  • Yes, he can help Joakim to finnish his work.

  • In this way they can resolve the bottleneck and move it to ready for development.


  • Great - another bottleneck resolved!

    But, if he couldn’t have done that either? What should Marcus had done then?
    Well - find other interesting work maybe. Prepare that automation of tests or get that pesky build server to run faster. Something to help the team.

    Strive to not draw new work. You could, and break your WIP limits - but remember that then all work to come will suffer and take longer time to complete.

  • We will now take a look on how your Kanban board can and should evolve over time.

    It’s not done - strive to find way to improve your process.
  • Say for example that you want your product owner to accept all items before shipping them.

    We add a new column for that - Accept.

  • And since the product owner is what is called a Non instant availability constraint we add a queue for things that is ready to accept.

  • And a column for accepted items.
  • The product owner cannot be with us all the time, but when she’s here she can accept many items at once. It doesn’t take to long.

    We allow up to 4 items in the Ready for Accept queue.


  • and as you see all items are quickly accepted when she had the time to sit down with and do it.
  • Here is another situation when we need to change our board.
  • Here is a situation where it’s not possible to share work and all Developers are busy on one feature each.
  • And suddenly a new Developer is added to the team. Mikaela is newly employed.

    What should she do?
  • This could be a time to increase the Work in progress limit.


  • And the she can draw new work.

    This could also be a indicator that the WIP limit was to low to start with.

  • With different work item types you can visualize how different kind of work should be treated in different ways. To enable the team to easier be self managed.
  • Up to now all the items on our board looks and are treated the same.

  • But they are not - this is a bug for example
  • And here is maintenance feature that we are testing
  • Over here is a change request that is waiting to be pulled
  • And these normal yellow ones are ordinary features
  • Now it’s more visual to us what we are working on. If the board goes all read with bugs we know that we’re having a quality issue for example.

    To remind us and others the colors meaning we could add a legend or key for the different items.
  • The cards we’re moving around could also communicate a lot of information.
  • First and foremost it should describe the feature. In this case in the form of a user story.

  • The use of an avatar is an easy way to show who is working on what.

    It could also be used to limit work in progress since you only can put your avatar on one card.

  • Here is a hard deadline added to the card - so everyone knows how we are doing against it.
  • If an electronic system exists with more information you could add the id of the item.
  • “Stamp” the date of each stage to get data for lead- and cycletimes that can be used to create cumulative flow diagram for example.

    This card entered the Analyze step 2010-01-19

  • and did not reach Development until 2010-02-01...

    What was going on there?
  • Use other items to signal deviations, such as delays or prioritization.

    As you can see we have plenty of room on our card ...

  • ... which makes room for another avatar, for when you pair program for example.

    It also forces us use ladders to move the items around on the whiteboard that holds these big cards :)
  • If we want our team to be self organized, we need to help them to know which feature to next.

    With classes of service we get a prioritization and policy approach that can help team members to chose their next work item.

  • A common situation is to introduce an expedite/urgent/silver bullet for things that is need to be prioritized over other work.


  • Those items are often given a own “swimlane”

  • Everyone is happily working on their items...
  • ... when suddenly an urgent feature is introduced.
  • A common policy for urgent features is that it should be prioritized over all other work. Just let go and start to work on the urgent feature to move it quickly through the whole process.

  • Phew - the developers were quick. The item is drawn by the tester and get going on it immediately.

  • And in no time the item is handled.
  • Another kind of policy is a minimum number or percentage of items of a certain kind.

  • So here we should strive to have 50% features, 12,5 % (1) technical stories, 12,5% maintenance and the rest bugs.

  • And with that policy in place Marcus, the tester, can easily see what the system should be filled with.

    A maintenance features since there are no maintenance features left in the system now that he finished one.

  • Here’s another situation.

    Test-Marcus is ready to draw new work. There are two items ready to be pulled.
    Which should he chose?

  • The maintenance features (light green) has certainly been in the queue long, but we have a policy in place that tells us to always prioritize features (yellow) above maintenance.

  • Test-Marcus can then easily know what to pick.
  • We all know the ceremony during a Scrum Daily Stand up. But is there a difference now that we’re doing Kanban?

    Notice that we’re still within the limits of Scrum - everything we have done so far can still be referred to as “doing Scrum”. It’s a bit advanced but still.

    We will let you know when we’re out of Scrum-country.

  • The major difference in Kanban standup is that the meeting facilitator enumerates work, not people.
    The board shows the status of the current work, queues and bottlenecks.

    When enumerating the work it is useful to traverse the board from right to left (downstream to upstream) in order to emphasise pull.


  • How is defects handled on a Kanban board? Can items travel backwards?

    This is one of the most common questions we get when doing this presentation. Here is some different strategies for handling defects.

  • When Test-Marcus finds a defect he could...
  • 1. Mark the feature as blocked
  • 2. Create a new defect card
  • 3. And place it in ready for development. Or maybe in Todo since it probably needs to be check by the designers and analytics team before development.

  • 4. Work on something else in the meantime. Given that Test-Marcus cannot resolve the issue himself.

  • Another approach is that Test-Marcus
    1. Mark his feature as blocked and
    2. Creates a new defect card
  • 3. and place it in the Urgent swimlane for quick processing
  • Test-Marcus could also.
    1. Mark his feature as blocked
  • 2. and call for help. The whole team is “swarming” on the issue and work together to resolve it.
  • You could further help the team in running the process with exit criterias for each column
  • By defining exit criteria for what is needed to move items into the Done column, we can reach a standardized work
  • We have now reach the point where you cannot call it Scrum anymore. We will start skip sprint planning and timeboxes and start doing our planning just-in-time
  • How is the backlog filled with new items?

    Start by filling the Todo-column or backlog with as many as the team usually comits to for a sprint.

  • Release the planning from the release and retrospective cycle and start planning just in time.


  • Maybe once every week or when event driven with an order point when new items should be added.

  • We are closing in on the order point
  • When all the items above the order point is moved the rest is moved up.

    Note the instruction card that tells you to call to a meeting to get new items in the backlog from the product owner. That is referred to in the industry as a Kanban card

  • Three new items is prioritized by the product owner...
  • and added to the backlog
  • A WIP-limit on the backlog indicates how much that should be planned
  • After a while you can use your data and the different work item types to predict how long before an item is release
  • This is referred to as Disneyland wait times, from the queues at Disneyland that tells you that you only have to wait 30 more minutes before 1,5 minutes of rollercoaster joy is yours.
  • Here we can see that the item on top only have 14 days to go before it’s in production
  • The board can be used to communicate other important information.
  • Here is a team member on vaccation...
  • ... and here is the same team member but sick, in the swineflu it seems but also some stomach disorder

  • Two-tiered/swim lanes.


Transcript

  • 1. Kanban in practice måndag den 19 juli 2010 (v.) This presentation will show how to adapt Kanban in your development project. There are quite a lot of slides and quite little text on each slide and the whole idea is that you should go through the slides quickly and a little animation effect will take place.
  • 2. About us • Avega Group • Joakim Sundén, Marcus Hammarberg, Christophe Achouiantz • These slides are protected under Creative Commons Attribution- Noncommercial-Share Alike 2.5 Sweden License måndag den 19 juli 2010 (v.)
  • 3. måndag den 19 juli 2010 (v.) One of the good things of Kanban is that it’s a evolution, not a revolution. You can adapt Kanban step by step. Start from your current Scrum board and enchance it to reflect your process. Actually - it will be many slides down before we will doing something that not fit inside Scrum.
  • 4. måndag den 19 juli 2010 (v.) So a good starting point could be to visualize your workflow. If you are working with Scrum you are doing that already. But maybe it could be a little more crisp than Todo, Doing and Done
  • 5. måndag den 19 juli 2010 (v.) Make some place for some more columns
  • 6. måndag den 19 juli 2010 (v.)
  • 7. måndag den 19 juli 2010 (v.) and move the “Done” items to that column
  • 8. måndag den 19 juli 2010 (v.) Often you start by analyzing a story, so lets a put a column to represent that work. - what’s included - how should it be solved - break down into task - etc.
  • 9. måndag den 19 juli 2010 (v.) And then we’ll add a column for the development of the story
  • 10. måndag den 19 juli 2010 (v.) And finally we need to verify and test the feature so that we are sure that the quality is good enough for our team to release.
  • 11. måndag den 19 juli 2010 (v.) One way of handling handoffs between specialists is to introduce queues so that work is buffered. In this way the next step can see when things are ready to be pulled from the Done-queue of the previous step. It doesn’t have to be hard specilization - even if it’s roughly the same people doing the work this can be useful to visualize the flow. So that we can where blockage, uneveness and other problems occur.
  • 12. måndag den 19 juli 2010 (v.) Let’s add a done-queue for development, to give a signal to Test when new work is ready to pull. In this case we added the Done-queue in the Development-step. You could also argue that it should be in the Test-step and be called “Ready for test” or something.
  • 13. måndag den 19 juli 2010 (v.) We now have our (simplified) work flow setup. Now it’s time to decided how to limit how much work we will allow to be in progress at one time - to Limit our WIP. There are some different approaches to come up with the total number for that: - 2 per person, so that you don’t get blocked. A bit less maybe. We don’t want everyone to be blocked - Equal to the number of persons in the team - The number of persons divided by 2 for experienced agile teams - Start from the bottleneck, the number of tester for example - Any number! We will change it as we see problems and opportunities.
  • 14. måndag den 19 juli 2010 (v.) Limit Work in progress for all columns or some, at least “Doing” We have limit Work in progress for Analyze to 2, Development to 3 and Test to 2 features at the same time. We have no limit for our backlog, Todo - but you very well could, to limit the flow into the system.
  • 15. Kanban-board A normal flow måndag den 19 juli 2010 (v.) We will now quickly demonstrate a normal flow on a Kanban board.
  • 16. måndag den 19 juli 2010 (v.) Here’s the intial stage...
  • 17. måndag den 19 juli 2010 (v.) Work is pulled from the backlog into the Analyze column as the WIP-limit allow.
  • 18. måndag den 19 juli 2010 (v.) You could wonder what Dev and Test is doing in these early stages of the flow... Well, the start will get a bit bumpy since no work are ready to be pulled. But this is for the very first time only, since a Kanban board never will be reset. In Scrum, for example, this situation is likely to occur in each sprint.
  • 19. måndag den 19 juli 2010 (v.) As work progress you monitor the flow of items.
  • 20. måndag den 19 juli 2010 (v.) Follow the WIP limits and only pull new work to your capacity
  • 21. måndag den 19 juli 2010 (v.)
  • 22. måndag den 19 juli 2010 (v.)
  • 23. måndag den 19 juli 2010 (v.) As we can see...
  • 24. måndag den 19 juli 2010 (v.) ... work is flowing along nicely since...
  • 25. måndag den 19 juli 2010 (v.) ... each step is only pulling work when it’s done ...
  • 26. måndag den 19 juli 2010 (v.) ... and not over their capacity.
  • 27. måndag den 19 juli 2010 (v.)
  • 28. måndag den 19 juli 2010 (v.) Tam-tam-tam - working with Kanban is a breeze!
  • 29. måndag den 19 juli 2010 (v.)
  • 30. måndag den 19 juli 2010 (v.)
  • 31. måndag den 19 juli 2010 (v.)
  • 32. måndag den 19 juli 2010 (v.)
  • 33. måndag den 19 juli 2010 (v.) We’ve started work on the last feature in our backlog.
  • 34. måndag den 19 juli 2010 (v.) About the same time as the first feature is ready to be launched! Yeah! Champagne to all!
  • 35. måndag den 19 juli 2010 (v.)
  • 36. måndag den 19 juli 2010 (v.)
  • 37. måndag den 19 juli 2010 (v.)
  • 38. måndag den 19 juli 2010 (v.)
  • 39. måndag den 19 juli 2010 (v.) And we’ve pulled the last feature into development.
  • 40. måndag den 19 juli 2010 (v.)
  • 41. måndag den 19 juli 2010 (v.)
  • 42. måndag den 19 juli 2010 (v.)
  • 43. måndag den 19 juli 2010 (v.) Now the development of the last feature is done and we’re ready to do the last bit of testing
  • 44. måndag den 19 juli 2010 (v.) The testers are working along to bring our goodness to the customers.
  • 45. måndag den 19 juli 2010 (v.) Closing in on the last feature.
  • 46. måndag den 19 juli 2010 (v.) And we’re done!
  • 47. Kanban-board Queue as a leading indicator måndag den 19 juli 2010 (v.) That wasn’t to educating since everything went well. It was good - but not educating... How do we handle problems? Let’s reset the board to a problem situation and find out.
  • 48. måndag den 19 juli 2010 (v.) Here all columns are fully loaded. Test is up to their limit and Development is finishing off the last story.
  • 49. måndag den 19 juli 2010 (v.) Actually, the Development team want to pull some new work. They are sitting idle...
  • 50. måndag den 19 juli 2010 (v.) But we cannot allow that - that would break their Work in progress limit off 3, now wouldn’t it?
  • 51. måndag den 19 juli 2010 (v.) So here we have a bottleneck in the Test-step. We want to move things along, but since Test are up to their WIP-limit we cannot. What’s good is that queues like this doesn’t happen instantly. You can see it build up and you can react to prevent it. The queue is a “leading indicator”. Compare that with burndown in Scrum which is an example of an trailing indicator that gives you the figures on how thing went. What to do? Theory of Constraints gives some options: - Exploit the bottleneck so that it’s used to the maximum, for example remove other work from them so that they are only doing testing - Elevate the bottleneck by increasing the capacity, for example employee more testers
  • 52. Kanban-board Starvation måndag den 19 juli 2010 (v.) Another thing to look out for is starvation.
  • 53. måndag den 19 juli 2010 (v.) This situation gives us empty columns or starvation.
  • 54. måndag den 19 juli 2010 (v.) The analyze don’t have anything done and Development is idle with no more work to pull.
  • 55. måndag den 19 juli 2010 (v.) This of course not good either but is another leading indicator. You can see when it’s about to happen and maybe react early, rather than face the figures afterwards.
  • 56. Kanban-board How do I draw new work? måndag den 19 juli 2010 (v.) That was some example of the flow of work on a Kanban board. But how do I draw new work? What are the strategies and rule I need to adhere to?
  • 57. måndag den 19 juli 2010 (v.) Here is Joakim - the tester - ready to complete the feature is testing right now.
  • 58. måndag den 19 juli 2010 (v.) Yes! It’s done!
  • 59. måndag den 19 juli 2010 (v.) What should he chose now?
  • 60. måndag den 19 juli 2010 (v.) Since there are work in progress in his column - the testing Marcus is doing - he should first and foremost see if he can help to finnish the work that is in progress. That’s our main goal - to finnish work in progress.
  • 61. måndag den 19 juli 2010 (v.) So Joakim and Marcus will test that feature together
  • 62. måndag den 19 juli 2010 (v.) They start to test it...
  • 63. måndag den 19 juli 2010 (v.) ...and before long...
  • 64. måndag den 19 juli 2010 (v.) ... that feature is also Done!
  • 65. måndag den 19 juli 2010 (v.) What now? Both Joakim and Marcus is ready for some more work. Nothing to finnish in their column.
  • 66. måndag den 19 juli 2010 (v.) But there are new work to be pulled from the Done-queue of the Development team.
  • 67. måndag den 19 juli 2010 (v.) Great! They draw new work...
  • 68. måndag den 19 juli 2010 (v.) Each starting a feature - to get work to be done as quickly as possible.
  • 69. måndag den 19 juli 2010 (v.) Another way to handling the siutation...
  • 70. måndag den 19 juli 2010 (v.) would be that they could work together...
  • 71. måndag den 19 juli 2010 (v.) ... on the highest prioritized item...
  • 72. måndag den 19 juli 2010 (v.) ... to quickly get that item done.
  • 73. måndag den 19 juli 2010 (v.) Look - they are on their way to be done
  • 74. måndag den 19 juli 2010 (v.) Well - that was quick! Great work guys!
  • 75. måndag den 19 juli 2010 (v.) Here is a case where Marcus, the tester is left with no work in his column AND no new work to draw. What should he do now?
  • 76. måndag den 19 juli 2010 (v.) Mikaela apparently wants some help, to get the item she’s working on ready for test...
  • 77. måndag den 19 juli 2010 (v.) But that is sadly not possible since Marcus is no programmer.
  • 78. måndag den 19 juli 2010 (v.) But... we have a bottleneck in Analyze. They are fully loaded and no new work is flowing from them. Both Joakim and Black-And-White-Marcus is working. Could Full-Color-Marcus possibly help over there?
  • 79. måndag den 19 juli 2010 (v.) Yes, he can help Joakim to finnish his work.
  • 80. måndag den 19 juli 2010 (v.) In this way they can resolve the bottleneck and move it to ready for development.
  • 81. måndag den 19 juli 2010 (v.) Great - another bottleneck resolved! But, if he couldn’t have done that either? What should Marcus had done then? Well - find other interesting work maybe. Prepare that automation of tests or get that pesky build server to run faster. Something to help the team. Strive to not draw new work. You could, and break your WIP limits - but remember that then all work to come will suffer and take longer time to complete.
  • 82. Kanban-board Inspect and adapt måndag den 19 juli 2010 (v.) We will now take a look on how your Kanban board can and should evolve over time. It’s not done - strive to find way to improve your process.
  • 83. måndag den 19 juli 2010 (v.) Say for example that you want your product owner to accept all items before shipping them. We add a new column for that - Accept.
  • 84. måndag den 19 juli 2010 (v.) And since the product owner is what is called a Non instant availability constraint we add a queue for things that is ready to accept.
  • 85. måndag den 19 juli 2010 (v.) And a column for accepted items.
  • 86. måndag den 19 juli 2010 (v.) The product owner cannot be with us all the time, but when she’s here she can accept many items at once. It doesn’t take to long. We allow up to 4 items in the Ready for Accept queue.
  • 87. måndag den 19 juli 2010 (v.) and as you see all items are quickly accepted when she had the time to sit down with and do it.
  • 88. Kanban-board New member in the team måndag den 19 juli 2010 (v.) Here is another situation when we need to change our board.
  • 89. måndag den 19 juli 2010 (v.) Here is a situation where it’s not possible to share work and all Developers are busy on one feature each.
  • 90. måndag den 19 juli 2010 (v.) And suddenly a new Developer is added to the team. Mikaela is newly employed. What should she do?
  • 91. måndag den 19 juli 2010 (v.) This could be a time to increase the Work in progress limit.
  • 92. måndag den 19 juli 2010 (v.) And the she can draw new work. This could also be a indicator that the WIP limit was to low to start with.
  • 93. Kanban-board Work Item Types måndag den 19 juli 2010 (v.) With different work item types you can visualize how different kind of work should be treated in different ways. To enable the team to easier be self managed.
  • 94. måndag den 19 juli 2010 (v.) Up to now all the items on our board looks and are treated the same.
  • 95. måndag den 19 juli 2010 (v.) But they are not - this is a bug for example
  • 96. måndag den 19 juli 2010 (v.) And here is maintenance feature that we are testing
  • 97. måndag den 19 juli 2010 (v.) Over here is a change request that is waiting to be pulled
  • 98. måndag den 19 juli 2010 (v.) And these normal yellow ones are ordinary features
  • 99. måndag den 19 juli 2010 (v.) Now it’s more visual to us what we are working on. If the board goes all read with bugs we know that we’re having a quality issue for example. To remind us and others the colors meaning we could add a legend or key for the different items.
  • 100. Kanban-board What is on a card? måndag den 19 juli 2010 (v.) The cards we’re moving around could also communicate a lot of information.
  • 101. måndag den 19 juli 2010 (v.) First and foremost it should describe the feature. In this case in the form of a user story.
  • 102. måndag den 19 juli 2010 (v.) The use of an avatar is an easy way to show who is working on what. It could also be used to limit work in progress since you only can put your avatar on one card.
  • 103. måndag den 19 juli 2010 (v.) Here is a hard deadline added to the card - so everyone knows how we are doing against it.
  • 104. måndag den 19 juli 2010 (v.) If an electronic system exists with more information you could add the id of the item.
  • 105. måndag den 19 juli 2010 (v.) “Stamp” the date of each stage to get data for lead- and cycletimes that can be used to create cumulative flow diagram for example. This card entered the Analyze step 2010-01-19
  • 106. måndag den 19 juli 2010 (v.) and did not reach Development until 2010-02-01... What was going on there?
  • 107. måndag den 19 juli 2010 (v.) Use other items to signal deviations, such as delays or prioritization. As you can see we have plenty of room on our card ...
  • 108. måndag den 19 juli 2010 (v.) ... which makes room for another avatar, for when you pair program for example. It also forces us use ladders to move the items around on the whiteboard that holds these big cards :)
  • 109. Kanban-board Classes of Service måndag den 19 juli 2010 (v.) If we want our team to be self organized, we need to help them to know which feature to next. With classes of service we get a prioritization and policy approach that can help team members to chose their next work item.
  • 110. måndag den 19 juli 2010 (v.) A common situation is to introduce an expedite/urgent/silver bullet for things that is need to be prioritized over other work.
  • 111. måndag den 19 juli 2010 (v.) Those items are often given a own “swimlane”
  • 112. måndag den 19 juli 2010 (v.) Everyone is happily working on their items...
  • 113. måndag den 19 juli 2010 (v.) ... when suddenly an urgent feature is introduced.
  • 114. måndag den 19 juli 2010 (v.) A common policy for urgent features is that it should be prioritized over all other work. Just let go and start to work on the urgent feature to move it quickly through the whole process.
  • 115. måndag den 19 juli 2010 (v.) Phew - the developers were quick. The item is drawn by the tester and get going on it immediately.
  • 116. måndag den 19 juli 2010 (v.) And in no time the item is handled.
  • 117. måndag den 19 juli 2010 (v.) Another kind of policy is a minimum number or percentage of items of a certain kind.
  • 118. måndag den 19 juli 2010 (v.) So here we should strive to have 50% features, 12,5 % (1) technical stories, 12,5% maintenance and the rest bugs.
  • 119. måndag den 19 juli 2010 (v.) And with that policy in place Marcus, the tester, can easily see what the system should be filled with. A maintenance features since there are no maintenance features left in the system now that he finished one.
  • 120. måndag den 19 juli 2010 (v.) Here’s another situation. Test-Marcus is ready to draw new work. There are two items ready to be pulled. Which should he chose?
  • 121. måndag den 19 juli 2010 (v.) The maintenance features (light green) has certainly been in the queue long, but we have a policy in place that tells us to always prioritize features (yellow) above maintenance.
  • 122. måndag den 19 juli 2010 (v.) Test-Marcus can then easily know what to pick.
  • 123. Kanban-board Daily Stand-up måndag den 19 juli 2010 (v.) We all know the ceremony during a Scrum Daily Stand up. But is there a difference now that we’re doing Kanban? Notice that we’re still within the limits of Scrum - everything we have done so far can still be referred to as “doing Scrum”. It’s a bit advanced but still. We will let you know when we’re out of Scrum-country.
  • 124. måndag den 19 juli 2010 (v.) The major difference in Kanban standup is that the meeting facilitator enumerates work, not people. The board shows the status of the current work, queues and bottlenecks. When enumerating the work it is useful to traverse the board from right to left (downstream to upstream) in order to emphasise pull.
  • 125. Kanban-board Managing defects måndag den 19 juli 2010 (v.) How is defects handled on a Kanban board? Can items travel backwards? This is one of the most common questions we get when doing this presentation. Here is some different strategies for handling defects.
  • 126. måndag den 19 juli 2010 (v.) When Test-Marcus finds a defect he could...
  • 127. måndag den 19 juli 2010 (v.) 1. Mark the feature as blocked
  • 128. måndag den 19 juli 2010 (v.) 2. Create a new defect card
  • 129. måndag den 19 juli 2010 (v.) 3. And place it in ready for development. Or maybe in Todo since it probably needs to be check by the designers and analytics team before development.
  • 130. måndag den 19 juli 2010 (v.) 4. Work on something else in the meantime. Given that Test-Marcus cannot resolve the issue himself.
  • 131. måndag den 19 juli 2010 (v.) Another approach is that Test-Marcus 1. Mark his feature as blocked and 2. Creates a new defect card
  • 132. måndag den 19 juli 2010 (v.) 3. and place it in the Urgent swimlane for quick processing
  • 133. måndag den 19 juli 2010 (v.) Test-Marcus could also. 1. Mark his feature as blocked
  • 134. måndag den 19 juli 2010 (v.) 2. and call for help. The whole team is “swarming” on the issue and work together to resolve it.
  • 135. Kanban-board Exit criterias måndag den 19 juli 2010 (v.) You could further help the team in running the process with exit criterias for each column
  • 136. EXIT CRITERIA måndag den 19 juli 2010 (v.) By defining exit criteria for what is needed to move items into the Done column, we can reach a standardized work
  • 137. Kanban-board Order point måndag den 19 juli 2010 (v.) We have now reach the point where you cannot call it Scrum anymore. We will start skip sprint planning and timeboxes and start doing our planning just-in-time
  • 138. måndag den 19 juli 2010 (v.) How is the backlog filled with new items? Start by filling the Todo-column or backlog with as many as the team usually comits to for a sprint.
  • 139. måndag den 19 juli 2010 (v.) Release the planning from the release and retrospective cycle and start planning just in time.
  • 140. måndag den 19 juli 2010 (v.) Maybe once every week or when event driven with an order point when new items should be added.
  • 141. måndag den 19 juli 2010 (v.) We are closing in on the order point
  • 142. måndag den 19 juli 2010 (v.) When all the items above the order point is moved the rest is moved up. Note the instruction card that tells you to call to a meeting to get new items in the backlog from the product owner. That is referred to in the industry as a Kanban card
  • 143. måndag den 19 juli 2010 (v.) Three new items is prioritized by the product owner...
  • 144. måndag den 19 juli 2010 (v.) and added to the backlog
  • 145. måndag den 19 juli 2010 (v.) A WIP-limit on the backlog indicates how much that should be planned
  • 146. Kanban-board Disneyland wait times måndag den 19 juli 2010 (v.) After a while you can use your data and the different work item types to predict how long before an item is release
  • 147. måndag den 19 juli 2010 (v.) This is referred to as Disneyland wait times, from the queues at Disneyland that tells you that you only have to wait 30 more minutes before 1,5 minutes of rollercoaster joy is yours.
  • 148. måndag den 19 juli 2010 (v.) Here we can see that the item on top only have 14 days to go before it’s in production
  • 149. Kanban-board Other visualizations måndag den 19 juli 2010 (v.) The board can be used to communicate other important information.
  • 150. måndag den 19 juli 2010 (v.) Here is a team member on vaccation...
  • 151. måndag den 19 juli 2010 (v.) Here is a team member on vaccation...
  • 152. måndag den 19 juli 2010 (v.) ... and here is the same team member but sick, in the swineflu it seems but also some stomach disorder
  • 153. måndag den 19 juli 2010 (v.) ... and here is the same team member but sick, in the swineflu it seems but also some stomach disorder