On another cold day in February, I found myself in Dearborn, Mich., following my phone into the Adobe Hotel. It was time again for the Agile and Beyond conference. Here, in 2012, we gathered the first Council of Elders to discuss software delivery. Last year, we reassembled the council on the theme of schedule pressure. It has become a bit of a tradition.\n\n\nAfter a keynote on tech safety, the council gathered at lunch to discuss story mapping, which allows a team to move from product vision to prioritized list of stories in minutes. The council this time includes the following:\n\nSteve Rogalsky, a consultant with Protegra who flew in from Winnipeg, Man., to speak about changing the way you engage your team;\nDiane Zajac-Woodie, a business analyst from Erie, Penn.;\nHolly Bielawa, a conference organizer and expert in Scaled Agile Framework and lean methods;\nSuzanne Dalton, an operations manager, creative director and Web developer, and\nJagdish Karira, a capability manager with HP.\n\nAfter introductions and a quick bite, I turn on the audio recorder to talk about story mapping.\n\nKarira smiles in the bottom-left corner. Clockwise from him are Dalton, Kirk, Rogalsky, Bielawa, Zajac-Woodie and the author (taking notes).What Story Mapping Can Do For You\n\nMatthew Heusser, CIO.com: First of all, what is a story map \u2014 or, perhaps, more accurately, what problem does story mapping solve?\n\n\nRogalsky: It allows you to see the big picture in your backlog.\n\n\nKarira:: It helps with release planning \u2014 getting the release roadmap, knowing when a story will be through the cycle and getting to the end user.\n\n\n[ Analysis: Has Agile Software Development Gone Mainstream? ]\n\n\nRogalsky: It's also visual.\n\n\nBielawa: This help you create, and see, what your minimal viable product will be.\n\n\nRogalsky: Let's look at an example:\n\n(Image courtesy of Steve Rogalsky's blog .)\n\nYou have this one idea in your head. You need to get it out. It wasn't important, but you knew you had to remember it. You get it on the map, put it on the bottom and get it out of your head. Now, you can have conversations about the things at the top while being reassured that the idea was captured. It's amazing. Once it's on the bottom, people don't care anymore.\n\nEffective Story Mapping Doesn't Start With a Blank Slate\n\nCIO.com: So now that we've seen an outcome of the process, how do we build it, and how long does it take?\n\n\nRogalsky: It depends on how big is your application. We had a small project, one or two person-months, that we story-mapped in 10 minutes.\n\n\nCIO.com: But somewhere you start with a blank piece of paper. Where do you start?\n\n\nZajac-Woodie: I usually build an initial map myself instead of with everyone at once. I find that people are paralyzed by a blank sheet of paper. As we review the map, people have an easier time agreeing or disagreeing with what's already there. Once they get started, they rearrange and add things.\n\n\nRogalsky: With or without a requirements document, I like to do this at the start of the project to get to know the customers and their needs. We had one large project that took about three hours to perform the initial map, then a few hours of improvement.\n\n\nZajac-Woodie: That matches my experience, too. A half-day initial session with all our stakeholders; then we treat the map as a living, working document that we keep updated and refer to as needed.\n\n\nRogalsky: What's really neat is that, by looking visually, your customers can tell you if they see holes.\n\n\n[ Commentary: Why 'Agile Project Management Controls' Isn't an Oxymoron ]\n\n\nBielawa: You're talking about seeing holes. One mistake I see people doing is going right to a story map without having doing an actual business model canvas or gathered data on who the customers are and what they need.\n\n\nZajac-Woodie: We use personas to create a picture of our customers and their need,s and we use those to inform our decisions as we build a map. I think personas are an important part of creating a map when you don't have real users to talk to.\n\n\nDalton: So do you bring users in the process?\n\n\nBielawa and Rogalsky: Yes.\n\n\nBielawa: You may have to go out and find them.\n\n\nRogalsky: There's a company in Winnipeg named UnionWare. They created a story map and showed it to the users at a user convention. The users tore it up and created a new one. That prevented building a product that wouldn't meet the users' need. Give someone a document and have them do that.\n\n\nLike Cartography, Story Mapping Comes in Many Forms\n\n\n\n\nCIO.com: How do you create the actual map?\n\n\nRogalsky: There are many ways to create a story map. In the end, you have a story map. You can do it from a requirements document, you can do it silently, you can do it in Excel, you can use CardBoardIt.\n\n\n[ Analysis: Who Says Agile Development Can't Be Faster? ]\n\n\nBielawa: I recommend that you know two things before story mapping: the goal, usually to make or save money, as well as the user goals.\n\n\nRogalsky: The columns are user activities, user tasks and user stories. Start with user tasks (in blue), what the users can do. From there, we group those into common tasks. Those groupings become the user activities (in orange). After that, we add the yellow stories, which the technical team will develop further and actually implement.\n\nThe parts of a story map include user activities (orange), user tasks (blue) and user stories (yellow). Source: How to create a user story map by Steve Rogalsky.\n\nWe have a lot of stories around our board.\n\n\nDalton: How long is the planning horizon for the first slice?\n\n\nRogalsky: Jeff Patton, who taught me this, says that you should be able to build the entire release one row in one or two iterations. For email, you want to get something out that's ugly and working. For email, if you can get a web page with a From field, a To field, a Subject field, a Text field and a Submit button, wham, you have an email feature.\n\n\nOnce the feature exists, the customers will give you feedback on how to steer. That's the business side. On the technical side, you have validated that your architecture is working; you have implemented the solution end to end.\n\n\nBielawa: It's also a really awesome way to burn down risk end to end. If you're doing a story map and you get the user from the home page through the order process, you've burned down all the technical risk to get to production.\n\n\nWhen you look at stories, your technical team asks, "What's the hardest stuff?" Those are the things we want to get done first, as simple as possible.\n\n\n[ How-to: 3 Ways to Be More Agile With Software Shipping Decisions ]\n\n\nRogalsky: You can do log-in so easily to test it. Just type in a name and allow it. You won't deploy it to production, but that gives you enough to begin testing the whole app, end to end.\n\n\nI don't want to misrepresent. We build the first slice in the first iteration or two, but hardly does the customer approve that to go out. The potential is there.\n\n\nBielawa: Right. That's usually a business decision; do we have enough?\n\nDo Story Mapping Right, Your Projects Come With Less Risk\n\nKirk: I'm really more excited about tech safety.\n\n\nCIO.com: We've heard that mentioned before. How does this encourage safety?\n\n\nKarira: All the things Bielawa said. We test the market, validate the product and drive out the technical risks.\n\n\nRogalsky: Let's get another example of end-to-end implementation. We implemented an insurance application. Our first release was for a group that only had dental coverage for the employee. We could have deployed it even though there was still additional functionality to be implemented for families and other types of coverage. Often, if we're working on an application that has search functionality, our first release only has search capabilities on the primary key of whatever we're searching.\n\n\n[ How-to: Use Agile Development to Avoid Project Failures ]\n\n\nBielawa: Some time people break stories into tasks. It's very hard to see when you're working on a task, what does this have to do with anything valuable? Sometimes developers will be completely disconnected from the story they provide. Some of the best times I've had, I've been looking at a story map and a story with a developer, and the developer says, "That's crap. What part of the story map are we even talking about right now?"\n\n\nRogalsky: I had a developer once tell me this was the first time he's seen the whole picture to actually know what he was working on.\n\n\nBielawa: When I do this, the developers always talk about the technical risk and burning down that, while the business users want to get the core functionality out. It's a great way to get that negotiation to occur.\n\n\nYou can do different levels of story maps, too. You can break out the functionality and map that. I've used XMind to document a story map visually. You can show all the colors and make it much like a physical story board as possible. That allows you to change the story map over time when priorities change.\n\n\nMatthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.