On a previous project we used a white-board wall for release planning – a ‘Release Planning Wall’. As it became quite an important tool for us, I thought it would be pleasant to post our ‘wall configuration’ here for future use.
The release planning wall is quite different from a typical ‘card wall’. A standard card wall will track stories through their life cycle (i.e. ready-to-play, dev complete, QA complete etc) and would cover one to two iterations. This wall tracks stories in the overall context a particular release.
The rather squashed up image below can be seen properly here. I should point out that the diagram uses dummy data.
Below is a real application of the release planning wall, as modelled above.
As you can hopefully see, the wall is essentially segmented into individual iterations that form a release. Above each iteration-segment is displayed the iteration number, the target velocity and the actual velocity (if that iteration has been played). In each iteration-segment lies information about each invidual story, including its title or primary reference, its estimate, and it’s status (quite simply, whether or not it’s been signed off). In the images above the status is simply a tick next to each story, the estimate a number.
The images above have the names of developers next to each story. This can be useful for communication purposes, but it’s not a crucial feature of the wall. It may not be applicable in circumstances where multiple development pairs are working on the same story in parallel.
The release planning wall serves a few objectives. Firstly it gives anyone caring to look at it an overall status report of the current release in play. It can be immediately seen which iteration it currently is, the work that has gone into the release thus far, the work that is outstanding, and the capacity the release has left for additional work to be squeezed in.
Secondly it gives release planners a useful tool when assessing which stories they can fit into particular iterations. I’ve seen many examples of customers and business analysts standing in front of the wall, discussing the timeline of when various stories can be played. By having a story’s estimate and the target velocity for each iteration at hand, they can easily determine if a story can fit into a particular iteration, and which stories they can perhaps juggle around so that this can be achieved.
Significantly, the wall gives context to the development team members. In enables everyone to visualize the breadth of the iteration, and where abouts development is in the overall time-line of the current release, and therefore to some degree the whole project. BA’s tend to ‘own’ this wall, while developers will typically make changes to the story card wall which is more granular.
Go Release Planning Wall!
Here’s another release planning wall using this format. This was taken some time ago and is now looking much busier.