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 present your team;
- Diane Zajak-Woodie, a business analyst from Erie, Penn.;
- Holly Biewla, a conference organizer and expert in Scaled Agile Framework and lean methods;
- Suzanne Dalton, an operations manager, creative director and Web developer, and
- Jagdish Karira, a capability manager with HP.
After introductions and a quick bite, I turn on the audio recorder to talk about story mapping.
Karira smiles in the bottom-left corner. Clockwise from him are Dalton, Kirk, Rogalsky, Biewla, Zajac-Woodie and the author (taking notes).
What Story Mapping Can Do For You
Matthew Heusser, CIO.com:First of all, what is a story map - or, perhaps, more accurately, what problem does story mapping solve?
Rogalsky: It allows you to see the big picture in your backlog.
Karira:: It helps with release planning - getting the release roadmap, knowing when a story will be through the cycle and getting to the end user.
[ Analysis: Has Agile Software Development Gone Mainstream? ]
Rogalsky: It's also visual.
Biewla: This help you create, and see, what your minimal viable product will be.
Rogalsky: Let's look at an example:
(Image courtesy of Steve Rogalsky's blog.)
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 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?
Zajak-Woodie: I usually build one map myself instead of everyone else at once. People don't like the blank sheet of paper. Then get people to rearrange or move 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.
Zajak-Woodie: That matches my experience, too: A half-day initial session, then a revision three weeks later.
Rogalsky: What's really neat is that, by looking visually, your customers can tell you if they see holes.
[ Commentary: Why 'Agile Project Management Controls' Isn't an Oxymoron ]
Biewla: 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.
Dalton: So do you bring users in the process?
Biewla and Rogalsky: Yes.
Biewla: You may have to go out and find them.
Rogalsky: We had 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.
[ Analysis: Who Says Agile Development Can't Be Faster? ]
Biewla: 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 activities, what the users can do. From there, we develop tasks in blue, the tasks the users can accomplish with our software. After that, we develop the yellow stories, which technical team will develop further and actually implement.
The 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.
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 feature end to end.
Biewla: 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.
[ How-to: 3 Ways to Be More Agile With Software Shipping Decisions ]
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.
Biewla: 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 Biewla 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 insurance application for a group that only had one person (a single person who only had dental coverage). We could have deployed it! If we implement search, it is search with only the primary key of whatever we are searching.
[ How-to: Use Agile Development to Avoid Project Failures ]
Biewla: 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.
Biewla: 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.
Matthew 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.
Read more about agile in CIO's Agile Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.