Understanding What Your Customers Want with Agile User Story Maps

[#1]

Article Written by Nick Muldoon
Product Manager with Easy Agile. Past Product Manager at Atlassian & Twitter. 

Here's what Nick covers in this article:

• Understanding the Customer as a Team
• Outcomes Over Output
• Release & Sprint Planning 

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 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 brings the customer journey to life, helping you understand what they want. Let's investigate why they are so successful. 


Understanding the Customer as a Team 

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 might look like. 

We needed to have a shared understanding. 

User Story Mapping is the best technique I've come across to gain shared understanding across 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 the 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 discussion and gives the 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.