Tuesday, April 05, 2016

User Story Mapping for Games - An Example

This article explains the basics of User Story Mapping and provides a simple example.

Years ago, I attended a lecture from Jeff Patton on User Story Mapping.  I was intrigued by his example, but struggled with how to apply it to video games.  Then, last year, he published his book on the topic.  The book is a great resource on different approaches and examples for mapping.  About this time I had a chance to mapping with a mobile game team.  Our variation on mapping worked well.

What is User Story Mapping?

User story mapping is a technique for creating a two-dimensional map of user stories usually
arranged by priority or a narrative of user activity on the horizontal axis.  The vertical axis often groups stories by sprints or releases (time).

Building the Example Map

It's useful to create a map for each release.  In a typical release, we'll usually start with a "Big Hairy Audacious Goal" or BHAG.  For our example, let's use a BHAG for a hypothetical car racing game:

"You are a fugitive driver, being chased, avoiding traffic and using your driving skills to escape Chicago!"

This is a good goal and a sizable chunk of work.  One of the first steps in release planning is to break the BHAG down into some smaller epic stories (stories still too big to fit into a sprint).

For our example, we have the following epics:
  • As a fugitive I want to drive a car fast to evade the police.
  • As a fugitive I want to avoid obstacles so I can keep ahead of the police.
  • As a fugitive I want to use the busy streets of  Chicago to lose the police.
With a bit of prioritization and refinement based on team structures, we can recreate the BHAG as a narrative made up of the epic stories:

This isn't the only possible arrangement of the narrative, but for this example, I arrange it this way to highlight the priority of the epics.  Obviously, driving the car is the most important.  It wouldn't be much fun if you can't evade the police.  Avoiding obstacles would be nice, but less important than the city and police.

Also note that the narrative isn't a set of user stories following the user story template.  The reason is that we want the narrative to be clearly readable as a whole tightly-coupled story.  The template can get it the way of doing that.

The next step is to forecast some sprints by:
  1. Splitting the narrative "epics"
  2. Sizing them by whatever method you use
  3. Prioritizing the split stories
  4. Placing them into their appropriate sprint (row) under the narrative epics (column).
In the example, the map might then look like this:

The colors represent the sprints (rows) for forecasted sprint goals.  The purple post-it in the lower right is large because it's still an epic.  We'll split that up after the spike (experimental work) on the ambient traffic in the previous sprint gives us a bit more knowledge about the work involved.

Why User Story Maps?

There are some advantages of user story mapping:
  • It visually organizes the work for a release.  I love the big picture view.  This can be used on games with a hundred people to give everyone a clear view of the shared goal and progress.
  • The narrative communicates "why" we are working on the stories.  I've noticed that teams using a map will respond to emergence better because they understand the big picture.
  • It's two-dimensional.  The one-dimensional view of a traditional product backlog is limiting.  Having multiple dimensions is better at handling prioritization.
  • It's very customizable.  For example, if you want to map a dependency, you can tack a piece of string or ribbon between two stories.
  • It responds to change very well.  We can shift stories, priorities and how work might be shared very quickly.
Other Useful Bits I've Learned
  • Build your maps with as many people as you can.  If you have 100 people on your team, have teams map out their columns individually.  This helps build a shared vision.
  • Physical boards trump tools!  I feel I'm a broken record on this, but maps don't take much space,  radiate information and can be instantly customizable and modified (sorry distributed teams).
  • Don't use post-its.  Although I use them in the art above, these maps live for months.  Index cards and cork boards, etc. work better.
Have fun mapping!

No comments: