When embarking on story mapping, smaller is better
Story mapping can be a revolutionary way to go about gathering requirements and scoping a new project. However, in my experience, many excited newbies go overboard and get so entrenched into their first real story mapping adventure that they end up with walls full of story maps, literally.
After several days go by, new information becomes available and the teams gain more knowledge, reality starts to depart from the plan, in this case the endless walls full of story maps. So, true to their agile culture and practices, teams add stories where needed and either remove or replace obsolete stories with more informed versions of them.
After a few weeks, the initial sense of pride and accomplishment starts to vanish and a sense of overwhelming angst takes its place. Every time a team member walks by the walls full of story maps on her way to the bathroom, she can feel the weight of all those stories on her shoulders – How are we ever going to implement all these? It would take us more than a year… Somebody please explain to me how this is being agile!
Months go by and paralysis strikes. The story map is so out of date, that everybody avoids looking at the walls. Nobody, and I mean NOBODY, wants to be responsible for maintaining them.
And this is probably why I was asked to be in charge of maintaining our two walls worth of story maps, containing 15 large boards, not that long ago.
After overcoming my initial reaction, we eventually managed to synch up a pre-existing digital version with reality, and I quickly proceeded to remove the story maps from the walls. I immediately experienced a great sense of relief, I could finally go to the bathroom without getting stressed out!
Since our initial gargantuous story mapping effort, we have learned our lesson.
We now practice just-in-time story mapping for specific features (rather than an entire projects) as part of the planning phase. Our resulting story map can typically fit in one large board, and is thus compact and portable, so that the team can take it with them to meetings, standup and wherever they go.
Just to make my stand on story maps clear, I love story maps. Their physicality makes for a great way to collaborate and discuss what it will take to build a feature (and a project). In fact, having followed the inception deck for a new feature recently, I realized that story mapping was the perfect tool to talk about priorities and what’s in scope / out of scope (i.e. drawing the MVP line).
The question that arises though is how about the high-level picture of the product? The 2-wall long story map did give us that, even if it’s just for a few weeks… Perhaps a more high-level epic map that allows product owners and other stakeholders to discuss and agree on the priority of all the features and which can be used to draw the product MVP line.
But then, one question still remains, i.e. how can we go about estimating the amount of effort required for a release if we don’t break epics down into estimable stories?
I believe the answer lies in relative sizing, but this only works once you have finished implementing a few features, and can ask yourself if this new feature you’re about to implement is about the same size, bigger or smaller than these other features.