Release Planning Wall

August 24, 2007 § 2 Comments

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.

release planning wall

Below is a real application of the release planning wall, as modelled above.

card wall

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.

release planning wall

  • Jason Yip

    We’re thinking about introducing a Release Planning Wall on my current project. The alternative of mucking around with a spreadsheet is getting old.

  • Liv

    I like that wall formation. We had a release planning wall but it was a bit more ad-hoc I like the target and actuals – makes it clear to everyone what is being aimed at. Cool!

What’s this?

You are currently reading Release Planning Wall at Pithering About.