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.

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