Story mapping points you at options that help validate customer value.
—Chapter co-author JP Beaudry
When you have determined that an idea is the highest-priority item to work on next, it is time to consider how you may validate its value to the customer. In the spirit of the Agile mindset, instead of attempting to build the full idea (that is, big batch), you should look at a way to build a portion of the idea to gain customer feedback. This is where decomposition comes into play and where user story mapping can help.
In this chapter, you will learn why big ideas should be decomposed and executed via smaller increments. Using the short form known as “story mapping,” you will see why it is an excellent tool for that purpose. You will understand the basics of doing story mapping, and you will see how story mapping and the artifacts it generates can fit in and interrelate with other tools in your Agile galaxy and along your journey to build and deliver customer value.
Why Decompose Ideas
Decomposing big, bold business ideas means slicing smaller increments that have customer value. It is a critical activity performed by Lean and Agile organizations. It is the core of what happens in the Refine stage of the enterprise idea pipeline, as illustrated in Figure 16-1.
Figure 16-1. Story mapping during the Refine stage
There are many reasons why you would consider bringing your big business ideas to market incrementally. At a high level, the arguments fall in one of two buckets: market reasons and technical reasons.
On the market front, the pace of change in customer tastes and in the availability of competitive products to satisfy those tastes has never been so fast, and it is accelerating. Can you believe that the ubiquitous iPhone is, as of this writing, not yet a teenager? In a world where change is the norm, the past is no longer a reliable predictor of the future. Logical deduction alone cannot identify which products or solutions your customers will adopt. But applying experimental thinking can help you discover them.
From a technical perspective, enterprises that participate in the creative economy never build the same thing twice. Indeed, when something has to be done more than once, it gets automated. Therefore, enterprises are usually solving problems that are new to them. Your own enterprise may be like that. This begs several questions. Do you have the technical capabilities to build the product? Can you do it at the speed that meets customer expectations and at a cost the enterprise can afford and customers can accept?
Agile Pit Stop
There are two reasons why you want to bring your idea to market incrementally—to better understand market needs and to reduce technical challenges.
Uncertainty surrounding an enterprise’s ability to deliver can be just as great as that surrounding market demand. This uncertainty demands a discovery mindset. Experimentation is core to discovery. Because success is not guaranteed, you must have the ability to run multiple experiments. These experiments should be short and inexpensive, yet yield as much information as possible. Experimental thinking is critical to the enterprise. The Refine stage of the enterprise idea pipeline is dedicated to cleverly decomposing big, bold business ideas into smaller increments.
Exploring Story Mapping
In the words of Jeff Patton, the person credited for formalizing the practice, “Story maps solve one of the big problems with using user stories in Agile development—that’s losing sight of the big picture.” He also calls this problem the “tragedy of the flat backlog.”
A story map is a visual representation of the user journey your enterprise seeks to bring to life. It’s a summary and reminder of the story you tell one another about what you are building, who you are building it for, what value the users will get, the options you have in satisfying user needs, and so on. Story mapping supports and promotes the conversation. It does not replace it.
A good way to see how story mapping works is to go through a simple example. You’ll first see the steps from beginning to end. Later on, you’ll get some practical tips on how to execute those steps.
Agile Pit Stop
Cutting increments of work via story mapping can help determine the value of an idea prior to the whole idea being built.
As an example, let’s imagine a bank that has a very basic mobile banking app. Customers can view balances and transfer money between accounts. Now, the bank wants to add bill payment capabilities to the app. How could the bank limit its investment, particularly in software development, to discover whether its customers are interested in such a capability? The story map will make the options clearer. While this example is about augmenting an existing customer experience (the mobile banking experience), the same concepts apply to greenfield initiatives.
Visualize the User Experience Backbone
The first step in story mapping is to describe the flow of the user experience at the highest level. Remember that story mapping primarily focuses on articulating the user experience and not so much on how to bring the user experience to life. In other words, story mapping helps define and organize requirements, and then passes the baton to the team to turn those requirements into products or services.
In the case of the mobile banker, the users in question are the bank's customers. The story map will describe their desired experience. You can think of the basic flow of the user experience as viewing account balances, transferring funds, and paying bills, as illustrated in Figure 16-2. Those big activities represent what is known as the “backbone” of the story map. Each backbone big activity goes on the top of the map.
Figure 16-2. Story map for basic mobile app
Determine the Steps
For each backbone big activity, identify the steps that the user undertakes. For example, “View Balance” is a step where a user “Selects an Account” and “Selects a View Type” (screen, statement, and so on). “Transfer Funds” is a step where a user “Selects Source and Destination” and “Determines an Amount.”
What about “Pay Bill”? One can imagine steps such as “Identify Payee,” “Define the Payment,” and “Execute the Payment.”
Identifying the Options
So far, the description of the user experience has been very high level and applies to all users. The next tier of the story map becomes much more detailed. For each step, identify different user-facing options that embody it. For the sake of brevity, the remainder of the example will focus solely on the “Pay Bill” backbone element, but the procedure is the same for the entirety of the story map.
What are the different alternatives the bank could offer its customers to “Identify Payee”? One option is for the bank to maintain a list of well-known merchants, credit card companies, and utilities, assuming that doing so would save time for many of its customers. At the other end of the sophistication scale, another option is to provide an empty text field where customers enter name and address of their payee. A variant of that would be to provide a form where fields such as street name, city, and zip code are validated. Another option still is to enable customers to scan paper invoices for payee details. There are likely many other options. Those options are entered under their activity on the story map.
This step is a divergent period with no judgment of the options. You should not yet be concerned with the value, the cost, the feasibility, the completeness, the competitive positioning, or the strategic alignment of the options. That will come later with convergence. For now, you are trying to generate good options. Consider a quiet divergent period so that all options can be considered and no one dominates the conversation.
Agile Pit Stop
High-level walk-through of story mapping: visualizing your backbone, determining the steps, identifying options, prioritizing options, and cutting an increment.
It’s time to flesh out the “Define Payment” activity on the story map. One user experience option can be to enter the amount of the payment. Another can be to select the source account of the payment. The goal is to identify as many options as possible. Another option could be the ability to schedule a payment for a later date. Yet another could be the recurrence of payment. The options are only limited by your imagination.
To finish off the example, the “Execute Payment” activity could have options such as immediate trigger, verification of fund availability, pre-submission review of payee and amount details, and so on.
Prioritize the Options
The next step is to prioritize the options in each activity from top to bottom. This is a convergent period where you start to look for those options that may help you gain customer feedback to validate the value of the idea or that can help you determine the technical feasibility.
The criteria for prioritization is context-dependent, but customer value should always play a prominent role. Other criteria can be risk, urgency, and so on. As you can imagine, there is frequently tension between various criteria. You will learn more about prioritization in the “Six Prisms” section and how to have a conversation to navigate that tension in the “Practical Tips for Story Mapping” section.
Cut the Increment
Now answer this question: Across all activities on the map, which options will you deliver to the customer first? Because some options are ambitious and because you have some uncertainty about what the customer truly values, you want to deliver a subset as soon as possible. Delivering all options at once is the textbook definition of a big-batch approach.
The mechanics are simple. Draw a line across the story map through the options. Everything you place above the line is explicitly targeted for your next increment, while everything below is deferred to a subsequent one.
The selection of what goes above the line is where the hard work and magic happen. As previously stated, in traditional or waterfall-style development where all features are released in one go, everything is above the line. But in Agile enterprises, there is a deliberate attempt to bring value to customers as soon as possible. There is also recognition of the limits of our knowledge; what you think has customer value is not validated until it is in the hands of customer. Therefore, the real question is what you move above the line and why.
Let’s explore how the bank could make that decision. If the bank is unsure that its clientele wants the online payment feature, it is in its interest to bring to market the simplest (and cheapest) thing that could possibly indicate customer preferences. After all, the bank most assuredly has many other ideas that compete for its finite product development capacity.
After some thought and collaborative discussion by the product owner, team, and a few key stakeholders, they consider a very simple implementation. This includes first selecting a checking account with a view on the screen and then selecting a basic text field for the payee, a payment amount automatically drafted from the ubiquitous checking account, and a review before execution. As illustrated in Figure 16-3 on the story map, those options are moved above the line, while the others are moved below.
Figure 16-3. Cutting an increment for the mobile banking app
A frequent objection to slicing such a thin increment from a big idea is that the increment doesn’t have enough features to satisfy all customers. Remember that the objective of this increment isn’t to satisfy all customers. It is rather to see if some customers find the concept useful. If the early adopter, David the Gen Y-er, doesn’t find online bill payment useful, then it’s possible that no amount of bells and whistles will attract the masses. You can learn more about minimalistic increments, sometimes known as minimally viable product (MVP), by looking up “customer adoption curve” and reading The Lean Startup by Eric Ries. This increment could have been crafted differently for many reasons. You will shortly learn about those reasons, also known as prisms.
The Living Story Map
Now that the map is created and an increment sliced, what do you do with it? First, use the story map to track the execution of the defined increment. In many cases, it may take several weeks or sprints to complete an increment. During this time, on the story map, you can indicate which options are waiting, work in progress (WIP), or complete, as illustrated in Figure 16-4. These options tie directly into your requirements tree. Options will become epics and user stories for one or more teams, based on complexity, and are placed into the appropriate product or team backlog.
Figure 16-4. Highlighting progress on your story map
As your teams discover what it takes to turn the increment into a working product and as feedback from the market comes in, you update the story map accordingly. Because an increment can take several sprints, you may learn during a demo that customers don’t like the idea and it may not be worth doing the rest of the increment. However, if they like the increment, this helps validate the value of the idea. In the meantime, amending the map can mean coming up with new activity options, redefining existing ones, and making new choices for what is in/out of the increment.
Six Prisms
To help you consider different ways to carve your thin increment, you can leverage the six-prism technique, as described in Deliver Early and Often by Emergn. The six prisms include value, geography, risk, stakeholder, urgency, and necessity. Each prism gives you a different lens to view your story map. The following are details on each prism.
Value asks which piece do customers value most? Instead of waiting to deliver everything, focus on delivering the highest-value piece first. The bank example utilizes this prism. Tools like cost of delay, as discussed in Chapter 12, can help you articulate value.
Geography asks if the product could be launched in just one of the many intended markets. E-commerce vendors that sell in many countries find value in using the geographic prism. If the bank operated a bilingual app in English and Spanish, applying this prism means it would go to market with just one of the two languages. The expense associated with translating into the other language would thus be deferred until the bank’s conviction that online bill payment is indeed good business.
Agile Pit Stop
The six-prism technique allows you to consider different ways to carve your increment considering value, geography, risk, stakeholder, urgency, and necessity.
Risk asks what the biggest risk to this project or its killer assumption is. Applying the risk prism means tackling that first. If the bank were outsourcing its development to a first-time supplier, that relationship would be a risk. Keeping the first deliverable small mitigates the risk because the supplier skills are assessed at the lowest cost possible. Generally speaking, a proof of concept is an embodiment of the risk prism at play.
Stakeholder asks you to think about important stakeholders, whose opinion may have a disproportionate impact on your ability to deliver. This may be a customer in the form of a persona. It may also be an internal stakeholder, such as an executive, who finances your idea. You can learn more about personas in Chapter 14.
Urgency gets you to confront important external deadlines. Has a competitor released a form of mobile that would compel your bank to go to market with a subset of bill payment as soon as possible? Is there a seasonal reason such as Christmas that may urge you to build something earlier? Beware of internal deadlines that can promote unhelpful behaviors.
Necessity asks you to consider the bare minimum you can get away with. Without this minimum, you are not in business at all. For example, our bank could ask clients to send it a text message with their payment instructions and could have its tellers process the payments. This is a very basic way to achieve the concept of “mobile bill payment.” Also, necessity can have you building just enough to avoid the fines of missing a regulation deadline.
Practical Tips for Story Mapping
As you consider approaching story mapping, there are a number of helpful tips to get you started. The following are some suggestions meant to maximize the value you get out of applying story mapping.
Streamline: A story map is a model to help focus thinking. It does not represent all the nuances of your application. Don’t worry about process flow forks; just serialize them.
Persona: A story map is typically written from the customers’ perspective, but sometimes your idea will have multiple user types. That’s OK. Just string the various flows side-by-side, taking note of the changing persona. You can learn more about personas in Chapter 14.
Just-in-Time: You are encouraged to resist pre-slicing many increments. You don’t need a second increment defined until the capacity to work on it is almost available. Premature slicing is akin to writing a plan. Humans fall in love with the plans they create, which makes them blind to feedback that may suggest the plan needs to be adjusted (in other words, confirmation bias).
Mob Creation: A way to get buy-in is have all types of stakeholders participate in the creation of the story map. Broad participation ensures that you get specialists from all areas. It also avoids triggering the question “Why wasn’t I consulted?” in those who weren’t represented. This is critical because humans are more vested in the success of the ideas they create than in the ones they are told about.
Diverge, Then Converge: As in many group exercises, you want to hear all the voices during the map creation. One tip is to do ten minutes of silent diverging when the map is first built. A facilitator should frame the story mapping exercise. Then people silently write their ideas for backbone, flow steps, and activity options on sticky notes or a digital tool. Then you facilitate a period of convergence where you identify affinities and remove duplicates.
Living Document: Shortly after an increment is delivered, you need to capture customer feedback. The people who sponsored the work should review that feedback and see if it influences how they want to invest their development capacity going forward. The story map should be updated to reflect the current state of work.
Public Display: Display the story map in an easily accessible public place. It provides transparency for the work and helps others know what the team is focusing on. It also makes an excellent backdrop for a variety of rituals such as planning, grooming, Scrum of Scrums, demos, reviews, and others.
Simplicity: In practice, Jeff Patton recommends building the map “middle-out” and let the activities and steps of the backbone emerge. The big activities are really just a summary of the steps that appear underneath. Smaller maps may not benefit much from this distinction. Only add the complexity if it helps your visualization.
Hypothesis of Value: Last, but perhaps most important, make the hypothesis of the value of the increment clear. When creating a story map, review the hypothesis for the idea and any details written on a canvas or idea pipeline record. If no hypothesis exists, then establish one. See Chapter 10 for how to articulate a hypothesis and Chapter 13 for how to create a canvas. Next, ask yourself whether the increment you have sliced is likely to result in the desired outcome and whether you are ready and able to measure a signal.
Can Story Mapping Help You Build a Better Story?
Decomposing big ideas into smaller increments allows you to better navigate the uncertainty inherent to the work of the creative economy. A useful increment seeks to validate customer value. It will do so quickly by being as small as possible. Incorporating customer feedback reduces the uncertainty surrounding the value of the big idea.
Story mapping helps you validate the hypothesis of customer value as well as the assumptions that underpin that hypothesis. You may find that it is useful during conversations to call out the primary persona. Understanding who the idea is for helps with the customer experience and the types of feedback loops that can strengthen the experiment. Getting all the brains to contribute is one way to manifest more of the collaborative Agile mindset.
Consider exploring story mapping. Which idea is your enterprise thinking about trying next to deliver value to your customers? How could you apply story mapping to deliver value or test critical hypotheses sooner?
For additional material, I suggest the following:
VFQ Delivery Early and Often by Emergn Limited, Emergn Limited Publishing, 2014
User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton, O’Reilly Media, 2014
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries, Crown Business, 2011