Creating our first story map

Posted: April 3, 2014 in Agile, Kanban, Product Backlog, Release Planning, Scrum
Tags: , , , , , , , ,

StoryMap

(This is part 1)

I liked the idea of story-mapping from the first time that I read about it. I’d done a couple of up-front sprint zero type exercises to create and size a Product Backlog at my previous company, and the feedback from the team about the exercise was that, once it got down to the relative sizing, it was hard to keep a grasp on the bigger picture and people often got confused about the relationships and boundaries between stories.

Simply, a story map is a way of maintaining a visual connection between stories as it shows the higher level user process (which also intuitively maps dependencies in 99% of cases) while showing the stories underneath. The other cool thing is that it’s a visual way to ensure one is doing vertical slices – by choosing stories in horizontal groups (so across the user process). Stories are also prioritised vertically adding the dimension that comes from the traditional Product Backlog. One of my team members, seeing our story map for the first time, described it as a ‘seven dimensional view’ of the project. Amazingly, although it has these many dimensions, it’s a pretty simple view to understand and can also be used to show progress.

If you haven’t already done so, I recommend you spend a worthwhile hour watching this video. I’ve also added some other links about story-maps below, but the video is still one of the best resources I’ve come across.

For this two-part entry, I’ll describe a bit of how our very first story mapping session went and some of the learnings I gained from running it. I intend to do some follow-up posts over time as our map (hopefully) evolves.

Our ‘project’ is slightly challenging to story map as

  1. We’ve already started working
  2. It’s about replacing something that already exists
  3. It’s related to our security architecture – so it’s very technical and quite difficult to map from a ‘user’ perspective.

My session (which ended up being two) followed the approach in the video quite closely, so had the following parts/steps:

  1. An intro in which I highlighted the desired outcomes and high level process that we would be following in the session. I also introduced the goal that was proposed by the Product Owner. This led to some debate as it was more business focused, whereas work to date (about a year) had been more about the technology. The team felt there were other ways to achieve business value using the existing infrastructure (a valid point). In hindsight, the goal may not have been the best goal for the session, but it did result in some much-needed debate and clarification and still helped keep the group focused on business value rather than technical goals. I did receive feedback that more up-front detail on the overall process we followed may have been useful in the intro as people weren’t always sure when it was the right time to introduce an idea/concept (none of the attendees were familiar with creating a story map before the session).
  2. The team (individually – silent brainstorming) wrote up stickies (all the same colour – purple) about the ‘things people do’. To help stimulate their thinking, I put up some typical users (we ended up trashing one of them). I also took them through the email example (just the user task level) to help get them to the right level. Once everyone was done scribbling, they did the grouping and naming exercise as demonstrated in the video. We actually struggled with our user tasks being too high level (e.g. manage xyz) rather than too low-level: it did help to try to get the team to start tasks with verbs where they had to break it down a level.
  3. We prioritised the groups and user tasks from left to right and ran through some scenarios. This highlighted a lot of gaps that hadn’t been clear before. At this point the group were getting quite tired and it was nearing lunch time. If I’d had time, I probably would have given everyone a long break at this point. As it was, we only had time for a coffee and tea break. Until now, all the work had been done on a large table in the centre of the room: I now put the skeleton up on the board (not wide enough) for the next part of the exercise. You need a very wide space for story maps!
  4. The next part was not done as comprehensively as we would have liked. We skipped writing stories for some user tasks that we knew wouldn’t be in our first slice and didn’t get into the detail of the second application we’d identified. We also did not write stories for work that we’d already done, which created some confusion later. We still got what we needed out of the exercise, but more time would have been good, and we will need to revisit parts of our skeleton. There’s also a (low) risk that some of the tasks we’ve left out for now are actually risky/important for our first slice.

That marked the end of our first session as we were already thirty minutes over time. Throughout the session, I encouraged the team to write down issues, risks and assumptions on bright pink stickies so that we could ensure we addressed them appropriately and did not forget about them. It also automatically created a parking lot, because anything that was relevant overall but not to where we were in the process could be parked (and eventually they did all find a home, either on the story map or as impediments in our impediment backlog).

Things that I felt worked well:

  • Being strict about using certain coloured stickies to represent particular things. This also made it easier to reproduce the map in a different location!
  • The email example was useful for framing what level we were speaking to.
  • The individual brainstorming and grouping approaches both worked really well. They got people on their feet and everyone engaged once they got the hang of it.
  • Do try to stick to the recommended 5-7 person limit.
  • The product owner was happy to see the team focusing on a business goal rather than a tech goal.

Things that didn’t work well:

  • We didn’t cover all the scope when we created our stories. We may have missed something.
  • Time. In the end, we needed three-and-a-half hours to complete both sessions (which wasn’t far off my gut feel of four hours).
  • Related to time, the team got tired. We could have done with more breaks.
  • The conversation about and agreement on the goal should have happened before the session.
  • Ideally this exercise should happen before work has started, as having done and partially done stories did confuse matters when creating the map.

Links

Advertisements
Comments
  1. […] you tried story-mapping? Was is successful? What worked for you? What did you struggle […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s