Last month Emin Tatosian posted an article about agile team-board layouts in which he showcases one of our more successful board designs. It’s fair to say that we don’t always get it right first time, so I thought I’d share an example of a layout that seemed to be a good idea at first but turned out to be badly flawed.
A few sprints ago I moved to a team in charge of maintaining our existing products and reducing technical debt. We had a backlog of low priority bug fixes and enhancements to work through and no specific client deadlines, so as team lead I thought this would be a good opportunity to try out the kanban methodology. After a bit of consideration the team came up with this board layout:
We thought that the workflow for any given story would be along these lines:
- A developer or pair of developers picks the top story card from the backlog and moves it to column 1. We use the power of three concept for pre-planning, so at this point the developer will go and grab the product owner and a QA engineer to have a quick chat about what the task involves. The acceptance criteria will be determined at this point. The card is then moved to column 2.
- Any free developer can pick up the card from column 2 and move it to column 3 to start work on it. At this point the developer should break the story down into tasks and place the task cards in column 4 as he works on them.
- When the developer is finished with the story he will get a QA engineer (ideally the one involved in the pre-planning stage) for a quick “show me”, to demonstrate the fix. The card then moves to column 5.
- A free QA engineer will pick up the card from column 5 and move it to column 6, then test the change thoroughly. This involves verifying the fix in every browser that we support, attempting to find edge cases, checking that sufficient automated tests have been written and so on.
- When the QA engineer is satisfied, the card moves to column 7 and is done.
That’s what we thought would happen, and we were fairly confident that the board matched our actual workflow. However when we put it into practice we quickly discovered that the adage about no battle plan surviving first contact with the enemy was coming true – cards were bunny hopping across the board with scant regard for several of the columns:
It was soon fairly obvious why this was happening.
- After the pre-planning stage (column 1) the developer would always begin work on the task immediately and move it directly to column 3 – it would be very odd for a developer to gather up the relevant people for a planning session and then leave the card in column 2, going off to work on something else. Column 2 is therefore completely redundant.
- Most of our stories were fairly trivial bug fixes which resisted our attempts to break them down into sub-tasks. This meant that in practice the entire story card would just be moved straight into column 4, skipping column 3 completely. This probably indicates that our stories were too small – it would have made more sense for a story to take the form “Fix 5 bugs in product X”, which can naturally be split into sub-tasks.
- After the “show me” session the QA engineer would almost always take on the testing straight away, moving the card straight from column 4 to column 6. Cards very rarely paused along the way in column 5.
Needless to say, this all came out during our first sprint retrospective and our kanban boards have evolved since that first attempt. But it taught me something – you might think that you can draw out your workflow with your eyes closed, but how closely does your theory match reality?