Kanban 1's Game Notes

Some notes from Kanban 1's Game's I've played at a few clients sites...

First, some teams have been exploiting the splitting rule. If they have a 4-work-item with 2 bugs on it, they simply split it into a 3-work-item and a 1-work-item and put both bugs onto the 1-work-item and then abandon it, and carry on with the bug-free 3-work-item. They have to check for bugs on the abandoned buggy 1-work-item but otherwise it doesn't affect velocity. This is obvious in hindsight but I hadn't foreseen it. It is amazing how simple rules can create complexity when used in combination. To counteract this I introduce a rule that when you split a work-item into two smaller work-items both new work-items get the bugs. So, for example, if you split a 4-work-item with 2 bugs into a 3-work-item and a 1-work-item, then the 3-work-item and the 1-work-item both get 2 bugs.

Second, the way backlog work-items are created (without any 1's cost), and then moved onto the first table (also without any 1's cost) creates another unintended (from my point of view), but nonetheless very interesting possibility that a few teams have also recently exploited. What they've done is simply created masses and masses of backlog work-items and immediately pulled them all onto the first table. They effectively move the entire backlog onto the first table. The price they pay for this is having to check for bugs on every work-item. Naturally lots of bugs accumulate on the masses of work-items on the first table. However, this does not directly affect the velocity since they can simply any abandon any buggy work-item on the first table and pull in a newly created bug-free backlog work-item at any time.
So I'm currently wondering if it's better to have to pay a 1 to create a backlog work-item and possibly also pay a 1 to move a backlog work-item onto the first table. I think this will be effective for two reasons

• it simplifies the backlog rules a bit since I can now drop the rule that backlog work-items have to move onto the first table in strict creation order.
• I can allow 1's thrown from any table to create backlog work-items. This will give players on tables other than table 1 something to do during the early days of the sprint.

It seems clear to me that the game should somehow take into account the total number of bugs on all work-items on all tables. I'm pondering that.

Thirdly, rather than recording the bugs on an index-card paper clipped to the work-item, simply use the paper clips! Two paper-clips on a work item (as in the photo) means two bugs. Much simpler. Again this is obvious in hindsight.