Skip to main content

Story Maps

I was startled to discover "story maps" a couple of months ago as an alternative to, or supporting documentation for, the "product backlog" or "master story list" (depending on whether you're Scrum flavored or XP flavored).  The maps should not have been a surprise to me:  it turns out a lot of the really cool agile teams are creating multi-dimensional "story maps" as part of their project inception.  In case some of you weren't aware of the story maps either, I just wanted to alert you before another day passes, and point you towards some help on the topic.   For the rest of you, why didn't you tell me??!

Jeff Patton posted this excellent overview of story maps versus backlogs in 2008, and as he says, this technique had already been used on the ground by a number of agilists other than himself for several years before that.  And responders to his post identified the story map as something akin to an old fashioned functional breakdown which dates back to the beginning of software development (say 1970, where unix time begins).

I strongly recommend that you simply read Jeff Patton's blog, but in case you're looking for a simple definition, here it is.

Recall that a "story" is a description of the behavior of a system described from the point of view of someone in the business.  In an agile project, stories are written on index cards.  For example:


As Patton says, in an agile project, the "requirements" for a new system would typically be described in dozens or hundreds of this type of story card.

A story map is an arrangement of these story cards which represents the sequence in which the stories will be needed by the business on the horizontal axis, and the priority of the stories on the vertical axis.  The horizontal axis should represent the minimum set of features needed by the system to allow it to be released.  As a corollary, you would typically have some large stories representing "user activities" across the top of the chart, in the order in which those activities would take place, and a breakdown of those activities into actionable stories in a vertical column under each of those activities.


In the example above, the "blue" cards represent a user activity, the sequence of blue cards indicates the minimum marketable features (MMF) for the product. However, for the team to actually build the system, they need to deliver some subset of the pink cards, which provide more detail about the blue cards.  Note that if you just delivered the first row of pink stories, you would have a basic system, and adding additional pink story cards below would start the gold plating process.

You can see how you could walk a stakeholder through this kind of story map, and they would immediately be able to see what you were missing, and you'd have a much better chance of delivering a complete system.

You might want to translate this story map into an actual "list" or "backlog" in your Agile Lifecycle Management (ALM) tool, but as Patton says, you would benefit by keeping the map around so that people can always revisit the big picture and orient themselves.

In other breaking news, apparently we "in the know" agilists now like to call "non functional requirements" "cross functional requirements" instead.  But that's fodder for another day.

Comments

  1. Another alternative to non-functional is para-functional, originally proposed I think by Cem Kaner

    ReplyDelete
  2. Well Elena, I've also been reading about story mapping lately and I am a bit confused about the small map you've depicted above. So the blue cards are the user activities, which actually are a combination of related user tasks. An example I have previously read about was the activity "manage email" that contained the following user tasks: compose, read, delete, ... email. You use verbs (actions users take) to explain users' activities and user tasks as titles. Furthermore the pink cards are merely features to me, and don't describe actual user (sub) tasks... . So to me the above map isn't the story map your fellow colleague Jeff Patton was talking about, or am I mistaken?

    ReplyDelete

Post a Comment

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica