Our initial Kanban board was pretty simple. It looked like that.
First thing was documentation. I know that’s not even trendy anymore to write documentations but yes, we do it. It helps us and if you add that we’re considering selling our products for the big companies which require documentations it isn’t even a matter of choice. Anyway, this was the part of our process and was usually started during testing and finished after testing was done.
The problem was documentation was sometimes omitted and specific features could go live undocumented. The answer was another column which appeared between Test and RTS. We set limit to 2.
To be honest after some time I’m not very happy with the column, or rather the way we incorporated documentation to the Kanban board, but for the time being it’s here. If it changes I’ll definitely let you know.
Another issue which appeared was connected with research we sometimes did. That time it was about choosing a framework to support web application development in Java. It wasn’t development of a specific feature, but rather a prerequisite to do one. However we wanted to see some kind of representation of the fact on the board.
So we added Design sub-column for Dev column. During design stage we split sticky-note feature to development tasks, adjusted architecture when needed and did research in cases like mentioned one. Usually sticky note made its way through Design stage very fast, but occasion it stood there for a few days so we knew what’s actually happening.
Design didn’t get its own limit but was incorporated into Dev limit since it more an early part of development or preparation for development than a separate stage which result in some kind of formal design document or something.
3. Testing limit
After clearing initial overload in test stage limit of 4 seemed to be a bit too loose. I also believed it gave too little incentive to push our post-its to the right side of the board as fast as possible. We changed a limit to 3 and it appeared as a good decision since only once there was a threat to break this limit, but quick reaction allowed us to avoid that.
After all these changes our board looked like that.
This is definitely not the final shape of our Kanban board, but we aren’t in hurry when it comes to adjusting it. It is much better to do just one change at time and see how it affects your work. Then you decide whether the change was good or not. That’s how above adjustments were done – incrementally one after another. And if you do your changes I encourage you to choose the same approach.