Don't Etch your User Story Map in Stone

I was having a chat with Adam Yuret last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples:

• Will anyone use it?
• Will anyone pay?
• Does anyone care?
• How will we make $?
• Can we build it?
• Do we understand the problem?
• Will this solve the problem?
• Will it perform adequately?
• Will it integrate with other applications successfully?
• Can we build this with the budget & schedule we have?
• What is the best architecture for this project?

When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. (Aside: Yes, there are sometimes excellent reasons to put things into a tool.)

Two quick stories to illustrate:

At a recent Agile Winnipeg event a local company (UnionWare) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."

For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.

In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn.

Subscribe to Winnipeg Agilist by Email