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.
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.
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.
Another alternative to non-functional is para-functional, originally proposed I think by Cem Kaner
ReplyDeleteThanks, Jason!
ReplyDeleteWell 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