As I was giving another version of my Discovery and Formulation training recently, I noticed again that one of the ways I use the story map as a basis for planning is quite unfamiliar to people, and I actually think that it is one of the simplest ways to help teams to actually start delivering in small iterations. So, I figure I’d write a short description of it here.
The training is about how to take a feature, break it into stories using Story Mapping, and then detail those stories further using example mapping and even write those examples down in the gherkin language that can be used as a basis for testing. To most teams, that is part of an activity called ‘Refinement’. That’s fine. However, even though the outcome of these activities are in shared understanding of the functionality we want to build, there are some other outcomes: we split a larger idea into smaller steps, feature into slices of the Story Map, slices into stories, stories into rules and examples. And by doing that we also consider, explicitly or implicitly, size. In other words, there’s some estimation going on, too! And estimation is part of planning.
Practices support and reinforce each other
When I got introduced to XP, way back, one of the things that really stuck with me was that all the different practices, whether they be technical or not, interact and reinforce each other. So when we get some planning and estimation input from the refinement process, it is a signal to see how we can combine those two things and let them feed into each other.
Story maps are refinement but can be the basis of planning
For me, this is how I tend to organise refinement and planning so that teams and organisations can actually do useful and dynamic planning without spending much time on estimation and forecast. I even tend to do away with most if not all other forms of keeping a plan, though I have found easy ways to fold the output of the story map into a high level portfolio view, for those that are into that sort of thing.
A quick reminder on the mechanics of story mapping
When we do story mapping, we get together with the whole team to discuss the way a feature we want to implement will let a user reach a goal. The conversation we have as we do that is hugely valuable in getting to a common understanding of the goal, the ways we can accommodate that goal in our systems, and how we can approach building the software needed to do that. The result of it looks somewhat like this:
If you’re not familiar with story maps, you can read more about them in my book, or even better Jeff Patton’s book, since he did come up with them. The result can look somewhat like the above, though there’s some differences in the way I use story maps that I’ll go into below.
What’s important to know about story maps is that they have a backbone, which are the steps in a workflow through our application that the user would go through to reach their goal. Those steps, called User Tasks are fairly high level. Under each step are user stories that describe functionality that would allow the user to complete that step. a single stories might enable the user to complete the step by themselves, or only part of it. That means that we can combine the stories under a step either incrementally, or iteratively: a bunch together might build to being able to complete the step (incrementally), or one after another might make it easier to complete the step (iteratively).
We can, then, combine stories for the different steps to create a combination that, together, would allow the user to complete their tasks and achieve their goal. We do that by putting them together in a Slice that combines that set of stories. A slice, in this way, can be a prospective release of the software, including all those stories, and specifically excluding the others, which are kept for a later Slice, and later release.
From release scope to sprint planning
This is the normal way we use Story Maps. There’s what I do with them that makes them more directly useful in planning: I time-box the slices to one sprint.
That is a small change, but it’s enough to be able to do away with most other tools for planning. As we go through the mapping exercise, when there’s enough stories on the board, and they are roughly prioritised, I simply draw a thin line on the board and ask the team to only put enough above that line that the work will fit into one sprint. Of course, I make sure to emphasize that this is just a rough idea, and will likely change over time. But just one sprint.
Then, another sprint, same process. When we have a few, I go back and ask them to name each slice. What is it that we are delivering here. I use Seb Rose’s definition of delivering value, in which value is anything that:
- Increases knowledge
- Decreases risk
- Generates useful feedback
That makes it easier to find the value that can be delivered in a single, hopefully one week, sprint.
From sprint planning to release scope
When we have a bunch of sprint-sized slices, perhaps 4 or 5, we discuss that idea of having a release. After which of these slices are we comfortable releasing the system to be used by end-users? Immediately after the first? Or maybe after the 3rd? Or is that still not an option after that 5th slice? Why not? What should be done to give us confidence we can release to end-users? Should we add a slice, or actually change the priority or contents of some of the earlier ones? Once we decide we know what brings us to that first release, we can mark it on the map, which I usually just do with a somewhat thicker line.
Since we have sprint-sized slices, and each has a name, we now have the main planning for a few sprints ahead including the sprint goal (the name of that slice!). There’s always things added to sprints that are not part of the main focus, but that is fine. The goal will keep us focused on progressing the feature work. If it turns out we were wrong in what fits in a sprint, well, we go back to the story map for each refinement anyway, and we’ll just adjust it as we go along.
Working in this way, the team is focused on a feature, and always has a clear view of what their goal is, and what the next steps are going to be. The lack of vision and a view of the road ahead is a common complaint for teams working in short iterations if there’s just the, often very long, backlog of small stories to lean on.
From team planning to portfolio planning
If you would like to use something like this, but need a clear view ahead across multiple teams, you now have the elements in hand to create a low-fidelity but actually accurate portfolio view of upcoming work. This works very well for a one-to-two month view ahead. It can be extended to three-to-four months but, like all planning, the use and accuracy of such plans diminishes the further ahead you try to see. In my experience, after about 2 months, teams often switch to a new feature, and a new story map, which means we have to create an initial story map for a feature further ahead than you usually want, but it is feasible.
Tools and definitions
Talking about planning, invariably the tooling question comes up. With teams that are open for it, I try to keep tooling to a minimum. In fact, only as we prepare to take a slice into a sprint would I normally put the stories into any issue tracking tool, keeping the backlog short, and the main focus on the story map. A lot of teams don’t have the liberty to work in that way, though, and will likely go through the trouble of keeping an electronic form of the planning in sync with an evolving Story Map.
So what if you need to map all this into a tool like Jira? The most straightforward link is of course to put the stories from the story map into Jira as a story. How do we map the slices? Even though we take in a slice in a sprint, just equating the sprint to the slice is not what we want: we want to register the thing we are making separately from the time-box in which we are making it. Because what we make when will change over time. The most natural mapping might be from a Jira Epic to a slice: we have a name, and a set of stories belonging to that defined increment.
In Jira, the way Epics are defined seems to have encouraged many to use them more as feature areas or categories instead of something that can can actually be completed. But in the end, an Epic is something finite. Another advantage of using an epic for each slide, is that it shows up nicely in Jira’s own portfolio view. The disadvantage might be that the feature itself, nor its releases, show up in that view. I recommend using Components for the feature area and, well, Releases for the releases, if you need to keep track of those. I also recommend not using anything you don’t actually desperately need, to avoid unnecessary complexity.