The Rules of Kanban:

Kanban software development is a form of Agile that focuses less on planning and more on the
flow of work moving through the kanban board. Because there is less planning, there is a
greater requirement on team members being disciplined about following the rules--that is, the
standards for how work flows through the board. Kanban is a pull system rather than the
push system most of us are used to. The goal of the kanban team is to keep work flowing
through the board.

Getting set up:

Agree on the following:
The most logical columns to break the work in to
Exit Criteria for each column
Initial WIP limits and policiesh for changing or temporarily breaking WIP limits
Policies for Expedited, Critical, and High priority items--Are estimates needed?
Does all other work stop?
What does deployment do to work downstream?
In Rally, your teams kanban board can be found under Track-->C360 kanban
Below are the standard rules. I will try to illustrate where possible
1. Work flows on the Kanban board from left to right
2. The Product Owner is responsible for the priority of the items in the kanban backlog.
Only the Product owner or someone he or she designates is allowed to put items in the
kanban backlog.
3. All team members need to consider the WIP limits for each column and agree on the
policies for changing them or temporarily breaking them.
4. All team members need to review and agree on the Exit Criteria in the Exit Agreement
for each column. An item cannot be marked as complete in any column until it meets the
exit criteria.
5. Team members generally have a primary column--the area in which they are strongest.
That is the column into which you will be pulling work as it becomes available.
6. Grooming will occur in 1 hour sessions each Monday to keep the kanban board charged
with stories to keep it flowing, but stories will continuously need to be groomed in the
elaboration column of the board.
a. Dev leads, tech leads and Product Owners will do the grooming.
b. If there are recommendations or considerations for tasking, this is a good place
to add them.
7. Only pull work from the the kanban backlog, pulling from the top first.
8. Never push work to the next column.--ONLY PULL
9. When you pull a story into your column, add the tasks that you feel you will need to
accomplish for it to meet the exit criteria.
10. If you need help adding tasks reach out to the Dev leads or tech leads on your team.

11. If you even suspect that someone else may need to accomplish tasks, contact that
person immediately so that they can add their own tasks.
12. Work is pulled from each column starting with the top most items that are marked as
Ready (green).
a. there is a certain amount of leeway given here. If you know you are the best
person to work on an item that is marked as ready, but it is second from the top,
go ahead and grab that second item.
13. You will not mark an item as Ready until all of the exit criteria have been met for that
column.
14. WIP, or Work In Progress dictates how many cards are allowed to be in a column at any
one time
a. WIP includes both items that are being worked on as well as items that are being
marked as Ready.
15. If your column has not reached its WIP limit, pull in the top most story from the left that is
marked as Ready.
16. You can only pull an item into a column where you will be working on it if the number of
stories/defects is lower than that columns WIP (Work In Progress) limit.
17. When you pull a story into a column where you will be working on it, you MUST make
yourself the owner of that item. NEVER make someone else the owner of an item. The
only exception is if you have asked someone to change the owner to your name
because you are unable to get to a computer.
18. When you pull a story in to your column, the Ready designation will automatically be
removed.
19. If, for some reason, you and another person both will be working on an item in a single
column, whoever is listed as the owner will be the one held responsible for that card.
20. Bottlenecks will occur and that is actually a good thing because kanban lets us know,
very quickly, where we need to make adjustments.
21. If all of the items in your primary column are marked as ready or are being worked on by
someone else, and you cannot help someone in your own column finish up his or her
work, look to the column to the right to determine if you can help move any of those
stories along.--clearing the way for more work to flow through and off the board.
a. --*exception: only up to Unit Testing. QA will handle QA work. Product Owners
will handle Acceptance.
22. If you cannot help with any of the stories to the right of your primary column, look to the
left of your column. (QA help with Dev. If you cant help with Dev, help with Elaboration.
23. There is a daily standup for the kanban board
24. The daily standup does not go story by story or person by person. Instead it focuses on
a. from right to left--are any stories blocked?--why, who can help resolve?
b. From right to left--are any stories marked as Ready? If so, will a team member
be able to pull that work in to the column to the right?
c. From right to left, are there any cards that have stalled--ie. sat in the same
place for more than two days?--why? The owner (the person who pulled that
card in) needs to be able to answer that question.

d. Are there any team members who do not have something they can be working
on?

Items marked as Ready:

In this case, Development has room to pull in the next available story from Elaboration. Even
though it is not the top most story, it is the top most Ready story. The team must be on the
lookout during the daily standup for any stories that appear to have Satlled or are not moving
forward.

In the example below, Development has hit its WIP limit. This means that a developer should
first look to the Unit Testing column to see if he or she can help there. If all three stories in that
column are owned and in progress, then the developer should look to Elaboration.

If you pull a story in to you column and exceed your WIP limit or if a story gets pushed back
from the right (If Unit testing or QA pushes work back) the column will turn Red to indicate you
have exceeded the WIP limit. In this case, Dev pulled in a story when they should not have.