Andy@Gigantiq

Like most agile projects, my current project uses a story wall (sometimes called a Kanban Board) for keeping track of the current iteration’s worth of stories. Typically these stories are hand written on index cards and stuck on the wall in columns to show the current status of each Story.

Story Card Wall

As the the stories status changes the card will be moved between the columns to indicate its progress. Currently our wall has the following columns:

• In Analysis: Stories that are currently in analysis.
• In Review: Analysis is complete but the story requires review by the testing and technical members of the team to ensure the story is ready for development.
• Dev Ready: Stories that are ready to be picked up by a development pair are listed in priority order in this column.
• In Dev:Stories currently being developed.
• QA: Stories currently under test.
• Complete: Completed stories.

Through a stories life cycle it will progress across the wall from left to right until it is completed. For each transition there is some kind of gating process to ensure that the story card is at a stage where its status should change. For some transitions we have multiple individuals involved in the gating process. It can be difficult to be sure that a all of the stories requirements for transition has been met. We found we needed a simple mechanism to keep track of the gating process that a story has under gone.

In our case, there are a few key transitions we monitor closely to ensure they occur:

• In Analysis to Dev Ready: Letting an ill prepared story in to development can be expensive and lead to a lot of re-work and a poor quality result. For this reason we ensure that during the review process a developer has carried out a technical review and that a tester has carried out a test review. The technical review is to ensure that the stories detail contains all of the required information for the story to be delivered with out ambiguity. The test review is an opportunity for the testers to familiarise themselves with the story and to augment the story with acceptance criteria in addition to the existing criteria the business has provided.
• Dev Ready to In Dev: Often the developers who pick up a story card for development are not the same person who carried out the technical review. As a result we have a “Kick Off” for each story which is an opportunity for developers, testers and business analysts to discuss the card and ensure every one has clear expectations of what is to be developed.
• In Dev to QA: Once the developers think they have completed a story we have a “hand over” where the developers walk the testers through the new functionality. This serves as an early check point with the testers to make sure that nothing obvious has been overlooked in the implementation of the story.

Over the months we have tried a number of mechanisms to try and keep track of the prerequisites for transitions.

1. Post-it notes: For a long time we managed with Post-it notes being stuck to the cards to show who had carried out the Technical Review and Test Review as well as if a kick off and a hand over had taken place for the stories. The obvious problem with this is that Post-it notes fall off and soon you loose track of what state a story is in.
2. Drawn Tick boxes: We then started to draw tick boxes on the new stories. Once tick box for each gating process. The intention was that who ever carried out the particular activity would tick the corresponding tick box and initial it. This worked reasonably well, though some cards did inevitably slipped through the cracks. Occasionally we would forget to draw one or more boxes and it also made some cards difficult to read if the spare real estate on the card was restrictive.
3. Printed tick boxes: I know this sounds a little over engineered, but we now have check boxes printed on transparent labels. Our business analysts place these stickers on each index card prior to placing it on the wall. Being a simple sticker makes it an easy amendment to any card. Forgetting to place a box on the card is less likely. Being an adhesive sticker, it will not fall off the card. Having transparent labels means that it can be placed on any card even if the real estate is restrictive.

For those of you who are curious, I have attached the word document for our labels here. In this file you will notice that each label has four check boxes. Each check box has an initial which is meaningful for our project. The meaning of each initial is defined as follows:

• QA: Testing review
• TR: Technical review
• KO: Kick off
• HO: Hand over

If anyone does think that using this may be useful to them, feel free to use the above document and modify it in anyway you please. This document was designed to work with Avery L7551 labels.

As a result of us doing this we are certainly finding that less cards slip through our checks and balances. More stories are a truly “dev ready” when they are picked up by the development team since they are less likely to have missed out on a Technical review or a Testing review. We can also ensure that kick off and a hand over of each story always happens.