Atlassian recently ran the Ultimate Wallboard competition where individuals and companies were invited to send in pictures or videos and descriptions of wallboards that they use to make their lives and jobs easier. Embotics submitted our Scrum wall to this contest and came away with an honourable mention in the Old School category.
The timing of the contest was a little unfortunate for us as we were nearing the end of a release and simultaneously preparing for a release. As a result, I was only able to provide a little colour to our entry but now have the opportunity to elaborate on what our big visible board contains and how it evolved to its current shape.
Our wallboard started our as a simple 4 foot x 6 foot whiteboard with lists of all the stories planned for the iteration and their current progress. Through team feedback in retrospectives and usage patterns, it has evolved into the form in the picture above. As we move offices, we will definitely be evolving it once again to make it better suit the way we work.
Currently, our board is divided into the following sections:
- lower priority stories for the current release
- expected stories for the next two iterations
- unstarted stories for the current iteration
- burndown chart and stories completed in this iteration
- retrospective items
- advanced work on the next release
The initial push behind our wallboard was to make the work for the current iteration available for all to see. For the first few iterations, we would put all the stories for the iteration up on a chart similar to D: work-in-progress and would track start and end dates for the development and testing of each story.
This worked very well to make things visible but it made it difficult to determine what exactly was being worked on at any one time. This led to the introduction of C: unstarted stories for the current iteration. We now had a place to park all the stories that had yet to be started, which led to two additional incremental improvements: we could easily prioritize stories; and we could measure and control the amount of work in progress. To gain further visibility into progress during the iteration, we followed some common advice and added E: burndown chart.
At about this time, we were fortunate enough to move into new offices that provided us with a very large wall that allowed us to include more information. To provided visibility to the team on what remained in the release, we added an early version of A: lower priority stories for the current release and provided space from the product owner to group the stories based on themes in one dimension and priority in the other.
To further refine what remained in the release and to provide the product owner with a working area for planning, we introduced B: expected stories for the next two iterations. By having this area, it became a very easy task for the product owner to publicly collect his thoughts at any point during an iteration and, more importantly, in advance of iteration kickoffs. This allowed many simple and potentially blocking questions to be raised and addressed when it was very inexpensive to do so. An important side effect of having the next two iterations sketched out is that it became very easy to see how long was left in the release by comparing the blocks of story cards on the wall. The low-cost estimation technique has been accurate to within one iteration at all times.
The last major addition we made to our board was the introduction of F: retrospective items. Like many teams, we were becoming very good at identifying things that the team could work on to improve our development environment and process but were sometimes not so good and following them through to completion when faced with the trade-off with product features. The obvious solution (after a number of months of not seeing it) was to introduce the retrospective items onto the main Scrum wall and ensure that we were allocating time during the iteration to address the items. The retrospective stories are printed on blue cards instead of white but follow our same walk across the board as other story cards. This is still an experiment in progress but their visibility means that we need to now actively consider them when choosing the next story to work on.
Our latest move is complete and we now have the opportunity to reshape our Scrum wall once again. Some of the things we will be looking at include:
- covering the wall with a tileboard material to provide an underlying 8′ x 24′ whiteboard
- experimenting with how to best handle two parallel development streams
- how a shorter iteration will affect the information that we need on the whiteboard
- how having the Scrum wall directly in our work area will affect its usage