Understand What Your Customers Want with Agile User Story Maps
My introduction to user story mapping came in early 2011 when I was the JIRA Agile product manager. We were exploring a completely new approach to supporting agile teams within JIRA; code name Rapid Board. We needed to revisit the way we framed our backlog and communicated our roadmap. And to our delight the user story mapping technique worked extremely well.
Prior to learning about agile User Story Maps, I’d simply add stories to the existing backlog ordered by customer value. As you can imagine, the backlog grew quickly and didn’t have much structure aside from the linear order of the issues. And with only the top 50 or so items ordered, the rest was a real mess.
The “flat” product backlog didn’t explain the customer’s journey or what they were trying to achieve. It was just feature after feature. Clearly this wasn’t the best way to represent the awesomeness that was Rapid Board to our customers or internal stakeholders.
User story maps bring the customer story to life, helping you understand what they want. Lets investigate why they are so successful.
The Whole Team Understands the Customer
To ensure Rapid Board was a success we needed to get the whole team on the same page: understand who our customers are, the problems they face in their roles and what a minimum viable solution may look like. We needed to have a shared understanding.
User story mapping is the best technique I’ve come across to gain shared understanding within an agile team. Every team member participates in the session and it may take from 90 minutes to several hours over a couple of days.
At the conclusion of a user story mapping session the team will have:
- alignment on who their customers are;
- a clear picture of problems their customers face;
- a backbone for the customers’ flow through the product;
- an ordered Story Map, ideally scheduled by version or sprint.
Outcomes Over Output
At Twitter, I met a team eager to build something, anything, just to show forward progress. There is a chasm between the output of a team and successful outcomes for their customers. And the success of a team is measured by outcomes, not code.
Running a user story mapping session with this team enabled them to clearly articulate their target user and the problem that user faced. From there the team identified a proposed solution to run as an experiment and see if it met their hypothesis.
Ultimately, user story mapping allowed the team to minimize waste and avoid building stuff users won’t value.
Release & Sprint Planning
Delivering iteratively allows an agile team to constantly learn from their customers and minimize waste. In addition to capturing the activities and tasks a user will undertake the story map also visualizes time. A key element of the story map is the ability to split the tasks out in to versions or sprints to show the sequence of work.
Splitting the large backlog by versions gives further context to discussions and gives a flat backlog depth and duration. This makes grooming and ordering the backlog far easier.
Finally, as the team progresses with delivery they can see their progress on the story map. They know how close they are to the minimum viable solution and what is coming up in a future release.
User story mapping is an essential practice for every agile team. Since my first user story mapping session for the Rapid Board in 2011 I’ve gone on to run over fifty sessions. Stay tuned for the next post where we’ll explore the anatomy of a user story map so you can run one yourself.
Part two of this series explores the anatomy of a user story map.
