By Nathan Donaldson
Tags: Agile
At Boost we’ve been running Agile projects (using Scrum) internally for about five years, and with clients for more than three. Constant refinement and improvement is a key feature of Scrum processes. For our scrum masters in particular, looking for ways to tweak our projects is a big part of what we do.
One way we do this is by trying practice runs of new processes internally before we unleash them on our clients. Recently we trialled story mapping as a different way to generate user stories, and then tested two different ways of prioritising the stories into a product backlog. We learned a lot from this, and are looking forward to trying it with clients soon.
Jeff Patton has done the most to formulate the method of story mapping, and he contrasts it to the traditional ‘flat’ product backlog. Patton argues that while a flat product backlog is good for helping the team understand what needs to be done next, it doesn’t help the team see the big picture of what they’re making:
Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?”
For my money, trying to understand the system – the whole system – is the difficult part of software development. One of the most common complaints I hear from Agile teams is that they lose the big picture – that is if they ever had it in the first place.
… [A] story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.
Occasionally on our Agile projects we’ve run into the problem where, although we’re working in order of priority and regularly delivering new functionality, it still feels like that new functionality isn’t building into a cohesive whole for users. We decided to try out story mapping to see if it might help in these situations.
For the trial we had:
I facilitated the story mapping, and Kriston, Gavin and Courtney took on the role of the team. Gavin was our Product Owner, and Kriston & Courtney played the part of topic specialists, there to advise the Product Owner on business and user needs. (Any combination of people could form the team for this exercise, but it’s important to make sure that the Product Owner continues to be the person making decisions about priorities based on business value, with everyone else there to advise and support them.)
The scenario we used was imagining we were going to launch an online card-sorting tool to complement IntuitionHQ, our online usability testing tool.
First, I asked the Product Owner ‘What will people do with this tool?’ (this is a more user-focused way of asking ‘What will our software do?’). The team brainstormed the high-level activities:
The Product Owner wrote each of these down on Post Its and and placed them in a row above a strip of builder’s tape on the wall.
Next I got the Product Owner to brainstorm the user stories that fell out of each activity, and stick them up in columns under the related activities. For example, under ‘Open and manage an account’, we had the user story ‘As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly’. We ended up with about 25 user stories across the four columns.
At this point, the user stories were in random order in their columns. Next I got the Product Owner to order them from most to least important within their columns.
After the stories were prioritised, I got the team to work together to identify a ‘walking skeleton’: the stories from each column we’d have to complete in order to have a first release of the software that was both high value and immediately useful. We put a line of builder’s tape across each column where the cut-off point fell.
Next we tried another way of selecting stories for the first release. We went through and roughly sized each of the stories, allocating 1, 2, 3, 5, or 8 points to each. (In the real situation, we’d have the people working on the project estimating like they normally would.)
Then I gave the Product Owner a ‘budget’ of $30 to ‘buy’ the stories they wanted to see in the first release (with ‘buy a feature’ prioritisation, you use a budget of between 1/3 and 1/2 the entire system budget, to force decision-making.) The ‘cash’ was in the form of small Post Its with $5, $2 and $1 written on them – so to buy an 8 point story, the team had to pony up a $5, a $2 and a $1.
It was fascinating watching the team change their mind about priorities with this spending limit in place. For example, in the first prioritisation, the story ‘As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly’ didn’t make the cut as a first release. In terms of opening and managing an account, this was originally seen as a nice to have, compared to the functionality to create a new account.
When faced with a limited budget however, the team decided this was the only story they wanted to buy from the ‘Open and manage an account’ column, reasoning that for a beta release, they’d be happy to offer the site just to existing customers. This released more cash to buy the essential stories associated with creating and distributing tests, and collecting and displaying results.
Based on current and previous projects, we know that a point usually represents about three hours work. Using this technique of estimating and ‘buying’ stories, we know we’d be able to give a client a reasonably accurate picture of what we’d be able to deliver within any given budget.
The scenario we picked – building an online card-sorting tool – was quite simple, and as we’ve built something similar we had a good understanding of what we’d need and how much work was involved. Our story mapping exercise was therefore quite straightforward, and we completed it in under two hours. In his article ‘How you slice it’ (download the PDF) Jeff Patton describes how to run a far more complex story mapping exercise. The overall goal remains the same: a useful and highly usable first release, which sets the stage for further iterations. As Patton writes in the article:
Incremental release may be one of the more valuable aspects of the various Agile development methodologies. An early release can help capture market share, generate early return on investment, and reduce money risked on software development. A strong early release can increase those benefits immensely. The model we’ve built can give you a better picture of your software’s features and help your organisation construct the most useful and coherent early release possible.
We can see a number of situations where this technique will be useful:
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.
Find out about the difference between prioritising and ordering.
Get tools to measure and improve how well you prioritise so you can reduce software development risk with Agile prioritisation.
Learn about working with stakeholders in Scrum.
