Sunday, December 12, 2010

Story Mapping is for Software

Story mapping is a very useful method for visually organizing the development of a software product. When we develop anything physical, story mapping ceases to be applicable and useful in the same way. Story mapping succeeds with software because software is intangible and can be constructed in almost any order. Software is only information. Both physical and software products can be described succinctly in the aptly named “elevator pitch.” Such a brief story can be implemented in software in an abbreviated path. Some input creates some output. Once it exists, a logical point in the code can be “widened” so that the point contains more complexity. If the rudimentary path can be demonstrated, each addition to that path can also be demonstrated. Refinement is everything and can be witnessed all the way.

Physical objects do not behave in the same way. I cannot create a real path through a circuit until some prototype of the circuit is physically built. Mathematical modeling is very useful, but it is only an approximation of the behavior of the real thing. Writing software is not modeling, it is the real thing. I can write instructions for building a wall, but the wall does not exist until it is built.

Story mapping involves listing major features of the software in some logical order. Typically the features are written on cards placed above a horizontal line, perhaps in the order they sensibly take following a work-flow path. Below the line, each major feature is decomposed (and described on a card) just enough that, taken from the beginning to the end, they form a “walking skeleton” of the software product. The logical flow of the product can be described, coded in rudimentary form, and demonstrated on a computer. Each element of the walking skeleton may be further decomposed as desired and written on cards that are arranged below their parent story. Another description of a walking skeleton is sometimes described as a rifle shot. A “rifle shot” through a proposed software product is a narrow path of functionality that includes every major group.

The horizontal axis of a story map is usually functional order. The vertical axis can be ordered in many ways, which gives the method it's power. Horizontally, one row of detailed stories can be assigned to each of the major user personas who will deal with the software. Rows can be assigned to software releases where everything in that row enhances the skeleton in the same logical way. Mapping elaborated stories in this way allows them to be arranged and developed in some strategic order. Commanded to produce the most valuable additional increment of user functionality with each sprint, the story map helps order work by business value. Story mapping as discussed here follows Jeff Patton's original description published in Better Software, January 2005.

Because the development of physical products proceeds differently, story mapping often leaves Product Owners in the physical domain scratching their heads over how to usefully apply the idea. Product functionality can still be arranged along a horizontal axis, but the order is somewhat arbitrary. We cannot order up a “walking skeleton” of our product from the machine shop. Product owners must create a strategic development path for each technology, each major feature. The concept of arranging product elements on a suitable coordinate system must be a bit more artfully applied.

The same objection applies to the "layer cake" and "sashimi" metaphors. With a physical product, thin slices are only sections and have no functionality or "business value" in Scrum terminology.