I love story maps. I love that they are big and visible. That at one glance you can see what is going to be delivered in the next release. That everyone can see what is coming up next.
It worked really well in the beginning. It assisted our product owner in thinking about what he really wanted and thus empowering him to prioritise and communicate the reasoning behind that easily. Its up on the wall in the team room and everyone can see it easily.
There were some drawbacks though. As its up on the wall – its hard to move to a meeting room for grooming sessions. That also means the product owner can’t use it when he’s communicating to customers/stakeholders. Another problem – as the stories get groomed they split up into smaller stories and your story map grows exponentially – and the wall couldn’t be extended… The product owner and myself were the ones updating the board … and I would prefer the team more involved in this. I believe a team that owns a story map with the product owner is the ideal to strive for.
We tried the online story map which was awesome, but as expected keeping the online map and the real wall map in sync quickly became problematic. (Especially as printing out and killing forests is something I’m loathe to do).
A few weeks ago I read this blog post by Roman Pichler and decided to try some out-the-box thinking with regards to our release planning.
I loved the idea of boxing the themes (as opposed to columns on a story board). I also like the product and UI design parts – but would prefer them closer(?) to the theme they belong to. The constraints filled a gap that was missing for me – but again I wanted them closer(?) to where they impacted a story. But this was enough to kick start my imagination 
We had a release planned in a four months time, so the first priority was to make visible what was wanted in the release at a high level, per theme. I put each theme on a piece of flip chart paper (from here on referred to as the theme page) so that it could easily be taken off the wall and carried to a meeting room for in depth discussion. Below is the “template” of the idea I implemented on each theme page.
Within the theme – we stick to a story map format. So the stories are broken down, with priorities (the theme priorities are in green), story point sizes (purple) and any/all dependencies visible. The idea here was that if the persona had various flows through a theme – those flows could be depicted on the theme page as well (red arrows). The priority for sprints is across themes is shown with pink stickies. This allows the Product Owner to prioritise stories across themes knowing where there are dependancies. Under each story are acceptance criteria – these are altered and discussed when the story is groomed and kept visible as a reminder to all.
To make it clear how many sprints we have until the release, and to show all team members holidays etc we put up monthly calendars down the side – laminated for easy changes – with all public holidays and leave etc on it.
Our release board is next to our sprint board in the team room. Big and visible, but with the ability to easily move to a meeting room.
What do you think of our Release Backlog?