I recently had the opportunity to discuss our Kan Ban board solution with other professionals and I was surprised with the diversity we had across our boards given our relative alignment on Agile. We had the usual expected difference on what columns and rows were on the board, but what surprised me were the differences on how the board was managed. How items got on the board and were moved on the board ended up being quite different.
Our board is what I would consider a relatively standard board. (Of course, I would have that position) We have limits for each of the columns on the board and the columns are:
- Analysis and Design
We also have rows that help to categorize the features. I have seen people create rows for individuals, but we wanted to keep it at a higher level to not imply that one person ‘owns’ the feature as multiple people will be working on the feature. (Note: we use the term feature but it equates to a User Story or a small collection of User Stories)
1) the level of Feature/User Stories that you track on the Kan Ban board can vary greatly. This was somewhat expected.
2) Can cards move backward? In my thoughts, I would move the card back to analysis if more analysis was required and then move it back to development when coding can resume. My friend would keep it in development the entire time. I would state neither is correct or incorrect, but it is interesting how we both modeled our board to get us the information we wanted. I primarily wanted to know what type of work was being done, while my friend was more interested in showing how long it has been worked on. (Cycle time) Either system can probably provide both, but it is interesting as to what each person’s preference was. The driving factor in this difference might be our background as I am more project management focused, while my friend is more developer focused.
3) Defects… My friend would create every defect encountered as a new card while I would consider the defects part of the original card until it has been accepted. (Once the work has been accepted and considered done, then any subsequent defect would be considered a totally new card) This difference was perhaps the most surprising as I just assumed that we would consider the feature in totality and creating a defect as a new card would perhaps give the false impression of done. Perhaps this is another indication of both of us using the board for different primary purposes. Again my friend was focused on flow of the work, while I was using it to manage done according to the stories we communicated to the business users.
There is no right way or wrong way to implement Kan Ban. That is one of the reasons for the easy adoption. I encourage you to try it and talk to your co-workers and friends. You may be surprised with the variations.