Story maps is a concept made popular by Jeff Patton and he started using them professionally before he even started to call them story maps. They were born from the need of having a better way of approaching complex agile projects, one that gives them a better chance to be successful.
But they're really close. I've started using story maps a few months ago and I find them a very useful tool. Here are a few characteristics of the projects I think story maps fit best:
* projects with rather limited time and budget
* projects where the client wants to see results fast
* projects where the scope is not that well defined or it is quite large
* projects whose scope changes often
* projects with a medium to large development team
If you work on a project that has 2 or 3 of these characteristics, then I recommend you to use story mapping to plan you project and create awareness of what you're planning to build.
Story mapping helps you to
* focus on what is the most important thing to deliver
* deliver often and deliver software that works
* easily make stakeholders aware of what you will deliver and when (high level)
* change priorities and scope easier
* visualise the (moving) parts of what you are trying to build
While I won't get into details, I would like to point out some of the core concepts that make all the money.
Before anything, you split your project in its main components. These are the top stories of your story map, also called the backbone. I like the car analogy that Jeff Patton mentions, the backbone would be formed out of the engine, the transmission, the brakes, the suspension and so on.
Some people would call these epics, because they are very large stories that you cannot really start working on. But I wouldn't see them as the classical meaning of epics that form your backlog, for the simple reason that most of these backbone stories will be completed when the project is over. If you really need epics in your backlog (if you need a backlog), I would model them around another concept of story mapping, details later on...
Next step is to split all these backbone stories into smaller stories, ones that are easier to grasp and you could maybe take them in a sprint (if you do sprints). Put the most important ones at the top and spread the rest towards the bottom or the least important ones.
One of the most important concepts of story mapping is delivering working software in iterations. You start with building a minimum viable product (MVP) or a walking skeleton, a version of the project that works, end-to-end (if possible), in a very basic way. And afterwards you add more features or improve existing ones in the later iterations until it's good enough.
I see the first iteration the most important one and maybe the most difficult to slice. And that is because you have to make the stakeholders decide on what are the most important things or characteristics to deliver first. And you have to be ruthless about it!
Making this or these first iterations too big and you will delay the moment where you get precious feedback. Also, you will learn a lot in these first iterations, that could change the way the next iterations will play along. Therefore, try to keep them small and focused.
One thing that brings value, is to set a short description for each iteration. What is each iteration about? What is the team trying to accomplish with it? This should keep the team focused and avoid scope creep. If you really need to add something else in those iterations, mark them as stretch stories as you probably can accomplish the goal of that iteration without completing them.
If you need epics, then I would suggest to consider the iterations as epics. This way they don't live too long and when they are done, you have something working.
1. As I see it, story mapping is about focusing on the important things and always being able to visualise the full scope at a certain point in time. Yes, the content of the later iterations will change, you can count on that!
2. The most important aspect of the iteration is _what_ it tries to accomplish and **not** _how much time_ it takes. Finish an iteration when the scope is done and not when the "estimated" allocated time passed. Sure, when an iteration takes longer, you should ask yourself why, but don't beat yourself up too much, especially when attacking the first iterations.
3. Story mapping goes well with [#NoEstimates](https://twitter.com/search?q=%23NoEstimates&src=tyah), so you could try to slice the stories in equal sizes and count them or introduce story sizes. The size wouldn't be used for fitting the stories in an interation, but just to be able to do better projections. So yes, you would be estimating in the team if a story is small, medium or large, but don't spend more than a minute on each, it won't bring value.
4. In order to do projections, you need some sort of data to build those projections on. Don't expect to be very good at predicting how fast you will deliver things when you are starting a new team. You need some time to get things into motion, to get better at story mapping, sliceing and doing all these things together in the team.
If you are interested in learning more about story mapping but not only, check out the following:
* Jeff Patton's [book](http://jpattonassociates.com/user-story-mapping/)
* Vasco Duarte's #NoEstimates [book and resources](http://noestimatesbook.com/)
I am still quite young in the world of story mapping and every time I start a new story map I try to improve some things. What you read above is based on what I read from different sources and also what I experienced myself. Don't be afraid to change the things you read about all these concepts, if it works for you, why not? Very few things are black and white and very few things apply to everything and everyone.
I hope you don't mind I assumed you're not using story maps in your projects. If you do, I hope you enjoyed this post, maybe you found something useful. Regardless, don't forget to leave your feedback on Twitter or email!