A life cycle is a series of floors!

Story mapping is a technique for visualizing and organizing a product backlog.  Story maps are useful for identifying a minimum viable product, for planning releases, for finding holes in the features product management needs and even for finding extraneous functionality that finds its way into every grouping of work. Story maps are so useful that they often thought of as a silver bullet. However, they are not a tool for every scenario that a team (or team of teams) might find itself facing.  All software products follow a fairly typical product lifecycle. Software products are created, enhanced and extended, maintained and then retired. While every piece of software follows this path, not every team participated in every stage of the life cycle. Story maps are not equally useful in each stage.

Product Development:  Arguably this is the classic scenario that story maps were developed to address.  Product owners, architects, and stakeholders collaborate to generate the epics, features, and stories that encapsulate their vision.  The story map translates a set of cards into a visualization that represents the customer’s view of the flow of the application.

Enhancing and Extending:  Adding features and/or fundamentally changing how a feature works often isn’t significantly different than a development project.  Use story maps to visualize the flow of the functionality in a product. Consider two major distinctions when using story maps. First, when using a story map for a new feature or enhancement, the creator of the map should consider whether they are going to use the same backbone (the top-level epics and features that the stories are then arranged under) as the original application or to create a backbone specific to the enhancement. The scope can be a major determinant. When extending the product to add a new feature it often makes sense to create a backbone specific to the feature.  If extending or enhancing a product broadly using the product’s original backbone as a guide may make more sense.

Maintenance: Using the classic story mapping approach rarely makes sense when addressing small enhancements or correcting defects.  The scope of the changes in this phase of rarely will impact the overall flow of the product or the general functionality of the product.  Note: I have seen issues purported to be problem tickets that were actually serious enhancements – call work what it really is.

Retirement:  In general story maps are rarely developed when retiring applications.  That said, one of the most brilliant approaches I have ever participated in used the concept of a story map to develop an understanding of a product that was on the slate for modernization or replacement.  As context, the support for the product had been outsourced and no one had a solid understanding of the whole application. This a common problem in today’s corporate environment. The map helped the team establish that understanding and to find hidden functionality.