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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…