The photo on the right shows how our planning board used to look a while back. There were 6 columns from left to right: Not Started, In Dev, UI Preview, QA Review, Customer Preview and Done. Each column essentially represented an opportunity to get feedback, e.g. from a graphic designer, a tester or the Customer. A story slice was expected to take a trip across the board from In Dev to Customer Preview and back and the story card earned an appropriately coloured dot for each column visited. There's duplication. The column a card is in and its last dot represent the same thing. Although all the dots together show the history of a story card. People also seemed to have trouble putting the cards back in the right place, even though their avatars are actually placeholders. Anyway, we decided to refactor the board.

Before I describe the new board format here's a bit of background. We use 1-week iterations . We do iteration planning every Wednesday , we estimate the stories in ideal pair days and we go to production at the end of every iteration. We also do slightly higher-level planning that looks out over the next 4 weeks and we use t-shirt sizing to estimate these stories. Together, these give us some goals to shoot for over a relatively short timeframe that is bigger than a single iteration, setting a direction if you like, and a nice small, coherent and prioritised backlog from which to pull stories.

Looking at the new board format in the photo on the left, you can see we've renamed the 6 columns. From the left, the first 4 columns read 4, 3, 2 and Not Started. The Not Started column contains the stories not yet started in the current iteration. Columns 2, 3, and 4 correspond to the weeks or iterations ahead and contain those stories that we think would be roughly the iteration content based on the t-shirt sizes. To the right of the Not Started column is In Process and on the far right is Done. We've retained the dots so now, when a card is started it gets a red dot and is placed In Process. When a story slice goes to the testers the card gets a blue dot and remains In Process. The same is true for Customer Preview but the dot is orange. When the story is done, the card gets a green dot and is placed in the Done column.

The dots are opportunities to obtain feedback. (A red dot for In Dev represents the feedback that occurs during pair-proramming .) The testers hold the blue dots and the Customer holds the orange and green dots. There's no pass or fail. The dots are simply given for the feedback generated. When the developers working on a story want particular feedback they have to go and have a conversation with the appropriate person and do a little demonstration to obtain the dot. For example, if a slice goes to the testers, the developers have a conversation with them, perform a demonstration and leave the card so they may conduct exploratory testing. In the meantime the developers are free to seek a pair swap and contribute to other stories already in play. When satisfied with the slice the testers give the card a blue dot and return it to the developers, providing feedback in another conversation. Something similar happens when the developers want to get feedback from the Customer. They'll have a conversation, walk the customer through the functionality delivered and get an orange dot. When shooting for Done, it's up to the Customer to accept the story and give the card a green dot. There is a prerequisite - the story must have gone through the testers one last time so that the whole story gets a preceding blue dot. This ensures the testers always play with the story in its final state and approve its candidacy for Done.