Story mapping offers a visualization of the steps, or stories, which make up a software development project. This conversation with several experts on the topic discusses how story mapping works, how maps are created and how stakeholders benefit from seeing the lay of the land.
By Matt Heusser
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.
After 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:
Steve Rogalsky, a consultant with Protegra who flew in from Winnipeg, Man., to speak about changing the way you engage your team;
Diane Zajac-Woodie, a business analyst from Erie, Penn.;
Bielawa: This help you create, and see, what your minimal viable product will be.
Rogalsky: Let’s look at an example:
You 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.
Effective Story Mapping Doesn’t Start With a Blank Slate
CIO.com:So now that we’ve seen an outcome of the process, how do we build it, and how long does it take?
Rogalsky: 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.
CIO.com:But somewhere you start with a blank piece of paper. Where do you start?
Zajac-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.
Rogalsky: 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.
Zajac-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.
Rogalsky: What’s really neat is that, by looking visually, your customers can tell you if they see holes.
Bielawa: 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.
Zajac-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.
Dalton: So do you bring users in the process?
Bielawa and Rogalsky: Yes.
Bielawa: You may have to go out and find them.
Rogalsky: 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.
Like Cartography, Story Mapping Comes in Many Forms
CIO.com:How do you create the actual map?
Rogalsky: 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.
Bielawa: I recommend that you know two things before story mapping: the goal, usually to make or save money, as well as the user goals.
Rogalsky: 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.
We have a lot of stories around our board.
Dalton: How long is the planning horizon for the first slice?
Rogalsky: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.
Once 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.
Bielawa: 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.
When 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.
Rogalsky: 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.
I 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.
Bielawa: Right. That’s usually a business decision; do we have enough?
Do Story Mapping Right, Your Projects Come With Less Risk
Kirk: I’m really more excited about tech safety.
CIO.com:We’ve heard that mentioned before. How does this encourage safety?
Karira: All the things Bielawa said. We test the market, validate the product and drive out the technical risks.
Rogalsky: 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.
Bielawa: 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?”
Rogalsky: 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.
Bielawa: 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.
You 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.