Creating a Product Backlog — Story mapping

Story mapping is at the front of my mind because I have spent much of last week helping out a new agile team to use story mapping for their first agile project, as you can see above. Also, I attended a recent agile meetup (under the auspices of the Melbourne Agile Business Analysts group) that covered the topic…see further reading.

When people talk about agile story mapping, a lot of people refer to Jeff Patton’s The new user story backlog is a map blog entry from 2008. At the meetup, it was mentioned that Patton admits that he wasn’t the first to come up with the idea of visually representing a product backlog. He views it as a pattern rather than an innovation, as he puts it in his plog post:

I always remind myself of the litmus test for a pattern. If you explain someone a concept and they say “what a cool idea!” it’s not a pattern. But if they say “we’re doing something like that too!” it’s a pattern. I’ve seen this often enough now that I believe it’s a pattern. – Jeff Patton

“Back of the door chunk priority list”

Here’s a war story about an agile product backlog that was created back in 2006 which is something like what is now commonly known as story mapping. I can see some aspects of the story mapping pattern in the way the backlog was assembled on that project. At the time, I didn’t really have a name for it, but if forced to name it now, it would be, “Back of the door chunk priority list”. Catchy, eh?

I was working in a hybrid Scrum Master/business analyst/project manager/product manager role, but with heavy emphasis on the Scrum Master duties. My Product Owner was a guy called Chris, who is now the Chief Operating Officer at a company called Brainpop, that specializes in educational animations. He has gone on to employ many agile/lean principles at that company, but that’s a different story.

Anyhow, Chris was responsible (as Product Owners are wont to do) for the vision of the project. Our Hollywood Pitch was “iTunes for Education”, such that we intended to break up monolithic bundles (CD-ROMs) of digital, educational content and allow people to buy small pieces and to allow people to sell their own content. That doesn’t sound too original in 2012, but in 2006 it was quite novel.

On that particular project, we decided to call the Themes in our product “Chunks”, for no particular reason except that it worked for us at the time. I think we treated them in a similar way to what Patton calls “activities”.

Chris and I had many (great!) ideas about what could be done with this web application, that we almost didn’t know where to start. Our brains were a collective broth of ideas, swirling around. We had to figure out a way of “mapping” them out, in order to figure out how our team could realise the vision.

We had a relatively new (to us), rather enlightened and experienced CTO. David, handed me a copy of User Stories Applied at the start of the project. I won’t say that it changed my life (too dramatic) but it certainly was a minor Damascene moment. Chris and I duly came up with Themes/Chunks for the product and using trusty index cards, we mapped out a priority for those Chunks.

The Chunks had titles such as Search (for content), Browse, Sort, Filter, Minishop, Global Player etc. You can see that some of them ended up being split up. We had a quarterly release/funding cycle; we called them “Stage Gates” or “SG”. You can see below that we were quite ambitious in what we thought we could fit into SG 1!

We also started to split the Chunks up so that that stories for part 1 could be prioritised ahead of those stories in the part 2 or part 3 of that Chunk.

The Chunks were stuck in priority order, on the back of the door of our little team room. Hence, Back of the Door Chunk Priority List.

Later, when stories were written, each Chunk had a plastic CD wallet that was pinned onto the Product Backlog wall. The Product backlog was divided into general Product Backlog (low priority), Warm List (upcoming and higher priority), and Hot List. Chunks that needed to be worked on to be ready to be put into a Sprint, were prioritised in the Warm List. Team members whose duty it was to produce wireframes, front end code etc. would discuss the stories with the Product Owner and developers and at the end of this, the stories would be placed in the Hot List, ready to be put into a Sprint. You can see the Warm List and Hot List on the left of the photo below.

This approach to mapping the backlog differs from the generally accepted story mapping practice of having the map displayed so that all of the cards from high level to more granular level can be used to tell the “story” and provide context for the activities that the backlog covers. I suppose we adapted to use the space available at the time and it wasn’t really a problem that the entire Backlog wasn’t unfurled on a wall. Team members would often dive into a Chunk’s story wallet, to make sure they knew what the Chunk consisted of.

Later, as we progressed through the backlog, the back of the door list evolved. Here is the BOTDCPL, some time later on the back of the door of a new, improved team room. The pink notes on each card show the story point estimates for each Chunk.

In a future post, I’ll show how we went about breaking down the Chunks into stories, ready for the Warm and Hot lists.

On the current project, mentioned earlier, the team followed the Patton Pattern (!)  more closely, as can be seen in the photo at the top of this article. I think that creating the story map as a team and having it visible to them, as development goes along is a useful and beneficial thing. Whatever way you choose to do it, breaking up the project and representing it visibly is definitely beneficial for an agile project, and I recommend you try it if you haven’t already.

Further reading about agile product backlogs and story mapping

Craig facilitated the Agile BA meetup and recently blogged about Story Mapping

I also have some guidelines for creating a Product Backlog. Includes a free download.