You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Here's what Nick covers in this article:
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.
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 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:
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.
Read Part II of this Article: Anatomy of an Agile User Story Map