Let's take a look at an example story map. I'll walk you through how to read this map and how a team would interact with the story map to develop the product. If you're new to me, my name is Mike Cohn, and I help teams succeed with agile. The story map I've created is for YumHub, a food delivery service. You've probably used a similar service. The first thing a YumHub user needs to do is enter the address where the food will be delivered. Then the user needs to select a restaurant. You can probably imagine there'd be a few ways different users might want to do that. One user might want to search for a restaurant by name. Another might want to see only Thai restaurants. Keep these different ways of selecting a restaurant in mind. We'll come back to them, but first we want to finish laying out the top row of the story map. After selecting a restaurant, a user will select the food they want delivered. I'll have the quesadilla. Then the user will set a delivery time, confirm the order, and finally pay. This row of a story map is called the backbone. It defines the main flow through a map, and it's read horizontally by mentally inserting the word then between cards. So we read this map as: first the user enters an address, then the user selects a restaurant, then selects food, then sets the delivery time, and so on. Story maps are two-dimensional, so let's add the second dimension to the map. Under each card in the backbone, you'll see alternative ways of doing that step in the backbone. Starting with enter address, our map shows three ways of entering the delivery address. A user can enter a new address, use a saved address, or use the current location. When you're adding these cards, you want to put them in priority order, highest at the top, lowest at the bottom. Here I've put enter new address at the top because I think that's the most important of the three. I don't think use a saved address can be the top priority because no one has any saved addresses until they've ordered at least once. And using the current location is great, but ever since I accidentally sent panang curry to my neighbor, I don't always trust my detected current location to be perfect. Because the cards in a column are alternatives, we can read down a column by mentally inserting or between cards. So here we would read that a user can enter a new address, or use a saved address, or use their current location. We'd continue reading the story map by saying, then they select a restaurant, then they select food, and so on. Across with then, down with or. In the next column, the user will select a restaurant. I've listed two ways of doing that. The user can browse the available restaurants, or the user can select a restaurant from past orders. Again, they're in priority order, and I put browse restaurants first because a user will not have past orders the first time they use YumHub. YumHub will let users select the food they want from either the full menu, past orders, or the most popular items at the restaurant. Then users can have the order delivered as soon as possible or schedule it for later delivery. After setting the delivery time, users can confirm their order or cancel their order. And then finally, I've listed three ways a user can pay for the order. Again, these are in priority order. Pay for my quesadilla with Bitcoin seems lower priority than paying with a credit card. I want to give you a tip that can really simplify working with story maps. Think of each card on a map as possibly containing a submap within it. To see this, let's drill down into the browse restaurant step of the map. I like to think of being able to metaphorically double-click on a map, and it turns into its own submap. So inside browse restaurant, we have this map. YumHub will let users filter by cuisine. You're looking for good Indian food. I still want that quesadilla. YumHub will also let users filter by star rating, which users can do by saying they only want restaurants with, let's say, four stars, or they can ask to see restaurants rated from four to five stars. Finally, users can also filter by price. They can do this by using preset price ranges YumHub will determine, such as $10 to $20, or a user can enter their own custom price range. Remember I said that you read across a map by mentally inserting then between cards. So here we have filter by cuisine, then filter by star rating, then filter by price. Some users will absolutely perform these steps in that order, but other users will perform them in a different order, maybe filtering by price first, and others may only filter by one or none of these options. It doesn't matter. Put the steps on a story map in the order you think makes sense, or in the order you think a typical user will perform them in. But don't obsess over the sequence in situations where things can be done in different orders. If you're mapping an email product, yes, write email needs to come before send email. But you'll encounter many situations like the browse restaurants case in which users may perform some, all, or no steps and can do them in any order. When story mapping, it's more important to think of as many steps and alternatives as you can rather than debating the order in which users might do variable steps. Story maps look deceptively easy, but they can be harder to create than they seem. It's worth it to take the time to get good at mapping interesting situations in your story maps. A good way to gain experience is to practice by mapping existing parts of either your product or a product you use often. If this video has been useful, please click the like button. And if you're new to the channel, click subscribe so you don't miss out on future tips to help you succeed with agile. Thank you for watching, and I'll see you next time.