Changing the World with User Story Mapping

Posted on : 8 Nov, 10:00 PM

Releasing a great application isn’t about throwing loads of features at a customer but rather about building the right product. 

Ever since Simon Sinek’s famous Ted Talk in 2009 entitled How great leaders inspire action, the importance of starting with the “why” in business has been top of mind.

The upshot of the talk and the movement that Sinek started was essentially this: customers don’t buy what you do, but why you do it. Sinek’s point seems so obvious today, but when it comes to product development, business leaders so easily lose focus on “why” their app matters.

In the rush to get to market and keep up with the competition, companies so easily focus on features, features, features. The product backlog for an application can so easily become “the thing” while the real reason behind the application gets lost in the shuffle.


Enter Jeff Paton’s user story mapping approach. According to Jeff, 

Jeff has written a useful book on the topic which is designed to help agile software teams build products that users love by staying focused first and foremost on the customer’s needs. 

At Integrant, where we build valuable applications for our clients in the manufacturing, medical device, and biotech industries, we found that Jeff Paton’s user story mapping resonated closely with our approach. Our aim for each and every client can best be summed up in Jeff’s famous quote:

“Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.”

In this article, we unpack user story mapping: what it is, why you need it, roadblocks to adoption, how to avoid a flat backlog, and steps to begin today integrating user story mapping into your own agile software development lifecycle.  

 

What is User Story Mapping and Why You Need It?

At a high level, user story maps are a simple, lightweight representation of the product development roadmap, usually done with sticky notes on a whiteboard or table. The real essence of user story mapping is for product managers and teams to list out the features that will create the most value for end users. As one source captures it:

A user story map is a powerful tool that enable an agile team to groom their product backlog and plan the product releases more effectively. A user story map captures the journey a customer takes with the product including activities and tasks they perform with the system. Creating a story map collaboratively ensures team members are on the same page from the start of the project through to ongoing development of new releases.

Instead of casting assumptions about how the customer will use the application, the team develops a dialogue or story from the viewpoint of the customer and how they will be using the product. The idea is to create an experience that is seamless, easy to use, and that can be navigated easily. The user story format should be captured in a simple to understand format:

 

"As a [type of user], I want to [action] so that [benefit]."

By framing up the user journey in these terms, the focus shifts from writing about features to discussing them. Through user story mapping, teams can ensure that the customer journey is personalized and that their story gets told.  

 

Roadblocks to Successful User Story Mapping

Every software project starts with a vision and a roadmap on how to build a product that users love. But somehow along the way it’s easy to mistake the forest for the trees. Development teams (and customers!) often get tripped up around understanding exactly what the application is supposed to accomplish. Feature bloat can easily take over and before long the project has become bogged down. There are a couple major roadblocks that can prevent user story mapping success. 

 

01 You’re working with complex queries and reports.

With SQL you can build one script that retrieves and presents your data. NoSQL doesn’t support relations between data types. Running queries in NoSQL is doable, but much slower.

The lesson here is that developers should focus on the “big picture” of an application rather than product features. Keep continually in mind exactly what it is this app is intended to accomplish. Agile development always tries to begin with what you know but it never should sacrifice the big picture for the small parts (features).  

02 You have a high transaction application.

In the business of writing code and building applications, it’s easy to forget what we’re doing and focus on the software instead of the business outcomes. One of the insightful stats in Paton’s book is that for any software project:

  • Only 20% will succeed in making a big impact
  • 60% have little or no impact
  • 20% will fail; releasing it will actually hurt the customer

The point here is that it’s easy to get stuck in discussions about technical features, architecture, and other minutiae without a clear path to outcomes. Unfortunately, a lot of money and time gets wasted in the software industry when well-intentioned teams build features that no one ever uses. The key here is to avoid the tragedy of the flat backlog – which happens when future features become a laundry list of “stuff to do.” Avoid this at all cost by adopting user story mapping, even if you think it’s too late. 

 

Never too Late to Adopt User Story Mapping

Maybe you’ve heard the term “Frankenstein application.” It basically the not so glamorous adage that has been assigned to an application with a mishmash of disparate and cumbersome features. Like the famous monster of the cinematic screen, some apps you’ve used probably were scary hard to understand. The application likely had unnecessary add-ons that didn’t have rhyme or reason. So, what happens if you happen to be on a team that has unwittingly built a “Frankenstein.” Is there hope?

Fortunately, yes, there is a way to course correct. The first thing to do is to stop and ask your “Why” and rediscover what are the most basic scenarios that you’re trying to provide to the end user.  

For example, you may have created an application to pay your cell phone bill. But somehow along the way, the app became a potpourri of other features like rebates, store locator, or quote engine for the best mobile deals.

Keep the big picture in mind; the most important thing is for the customer to pay their bills. Period. Staying deliberately focused on the customer journey is the most important way to avoid “feature bloat.” Focus on the big picture and make the main thing the main thing.  

5 Steps to Adopting User Story Mapping

So, how does user story mapping actually work in practice? Before jumping in, let’s reinforce the “why” by reflecting again on Jeff Paton’s famous quote: Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.


Our goal as software developers – and this is our mindset at Integrant – is to build powerful and elegant solutions that help our clients change the world. Let’s break down into 5 discrete steps what is required to adopt user story mapping successfully and how to create elegant applications that users love. 

 

01 Frame Your Idea

Before kicking off your user story map, create a short product or feature brief to frame and contain what you map. Think of this as the big story. Ask yourself the following key questions:

  • What? Here you name the product, or feature to add to a product, or identify the problem you’d like to solve.
  • Who? Here you identify the different types of users who will use the product, and the customers who will buy it. For each user, choose the benefit they get from using the product.
  • Why? Describes the benefit your organization gets by building the product or feature. Say what users do and how their use leads to increased revenue or reduced costs. 

 

02 Map the Big Picture

Focus on gathering the whole story. Think “mile wide, inch deep.” The activities and high-level user tasks that tell the whole story form the backbone of your story map. For example, the story below is a typical scenario we all face every morning – bathing and getting ready for our day. 

  • Start with the user type most critical to your product’s success.
  • Imagine a typical day in your user’s life with your new product.
  • Map the steps they take as user tasks from left to right.
  • Identify user activities – groups of tasks that work together to support a common goal. More activities often emerge after you see more of the story.

 

03 Explore

Fill the body of your story map by breaking down larger user tasks into smaller subtasks and user interface details. During this phase you’ll add cards, split one card into two, rewrite cards, and reorganize them. Use this phase to think “blue sky” about all the great possibilities. Use this time to think of everything that could go wrong. Don’t worry if your ideas are “in or out of scope.” You’ll deliberately move things out of scope later. 


  • Play “wouldn’t it be cool if ...” to help think of great product ideas.
  • Look for variations: What else might users of the system have done?
  • Look for exceptions: What could go wrong, and what would the user have to do to recover?
  • Consider other users: What might other types of users do to reach their goals?
  • Add in other product details like:
  1. Description of proposed UI
  2. Business rules
  3. Data elements

 

04 Slice Out Viable Releases

Slice your map into holistic product releases that span the users and use of the product. These slices form an incremental product release roadmap where each iteration is a minimal viable product release. 

  • For each release, name the target outcomes and impact. Outcomes and impact say how this release contributes to the overall goal. In other words, this explains the “big why” that motivates building the product, and how users will behave in a way that helps us reach the goal.
  • For each release, identify product success metrics. Answer the question: “what would we measure to determine if this product was successful?” Ideally, you’ll find specific changes in user’s behavior as they use the product the way your story map imagines. 

 

05 Slice Out a Development Strategy

Slice the first release of your map into three or more delivery phases that allow you and your team to learn fast and avoid risk. Think of the opening, mid, and end-game phases of a chess game. This development strategy will help you release the best product possible in the time constraints you have. 

  • Opening Game: Here you build a “functional walking skeleton” – the simplest possible functional version of the product. As you finish "Opening game" vet the product with users and other stakeholders. Begin validating performance and scalability.
  • Mid Game: Complete all major functionality and make the existing functionality richer and more complete. Continue user testing and leverage feedback to adjust the product. Continue testing performance and scalability.
  • End Game: This is where you refine the product in preparation for release. Continuously assess release readiness based on your release level product goals. Count on unforeseen work to merge during this last stretch of development.

  1. Plan the work necessary to refine stories and workshop stories with developers and testers in order to work through the details and agree on acceptance criteria.
  2. Plan development and testing.
  3. Build and verify parts of the working software.

 

 

Work With Us!

At Integrant, when we sit down with a new or existing client, our overriding purpose is to help them change the world. The result of our engagement will be an elegant, user-friendly application specific to the client’s industry or domain.


But our “why” is always the same. The reason Jeff Paton’s user story mapping system resonates so well with our mission/vision and values is that it assumes from the beginning that software is not about requirements, but about outcomes – ultimately changing the world!


The focus on mapping the big picture of the customer journey, understanding the intent of each user action, and slicing out viable releases while avoiding “flat backlogs” are all values that we hold near and dear at Integrant.


Does your business application suffer from “feature bloat” or is your team dealing with a “Frankenstein app” that has gotten out of control? No matter what the exact situation, we can help you right-size and get back on track.


At Integrant, we’ve been building applications for almost 30 years and know a thing or two about helping our clients bring elegant, user-friendly applications to market. We’re in the business of helping our clients change the world and would love the opportunity to help transform yours. Work with us to adopt a user story mapping approach – either to design and build an app from scratch or else turn around a “flat backlog” – in order to drive value and revenue for your clients.


If you’re looking for a partner to bring the right product to market, then give us a call today. We’ll teach you how to map out your user story, build the application, and grow beyond your wildest dreams.


Subscribe below or contact us to see the impact we can make for you and your business. We can’t wait to get started!

Thanks for subscribing!

Changing the World with User Story Mapping

Posted on : 8 Nov, 10:00 PM

Releasing a great application isn’t about throwing loads of features at a customer but rather about building the right product. 

Ever since Simon Sinek’s famous Ted Talk in 2009 entitled How great leaders inspire action, the importance of starting with the “why” in business has been top of mind.

The upshot of the talk and the movement that Sinek started was essentially this: customers don’t buy what you do, but why you do it. Sinek’s point seems so obvious today, but when it comes to product development, business leaders so easily lose focus on “why” their app matters.

In the rush to get to market and keep up with the competition, companies so easily focus on features, features, features. The product backlog for an application can so easily become “the thing” while the real reason behind the application gets lost in the shuffle.


Enter Jeff Paton’s user story mapping approach. According to Jeff, 

Jeff has written a useful book on the topic which is designed to help agile software teams build products that users love by staying focused first and foremost on the customer’s needs. 

At Integrant, where we build valuable applications for our clients in the manufacturing, medical device, and biotech industries, we found that Jeff Paton’s user story mapping resonated closely with our approach. Our aim for each and every client can best be summed up in Jeff’s famous quote:

“Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.”

In this article, we unpack user story mapping: what it is, why you need it, roadblocks to adoption, how to avoid a flat backlog, and steps to begin today integrating user story mapping into your own agile software development lifecycle.  

 

What is User Story Mapping and Why You Need It?

At a high level, user story maps are a simple, lightweight representation of the product development roadmap, usually done with sticky notes on a whiteboard or table. The real essence of user story mapping is for product managers and teams to list out the features that will create the most value for end users. As one source captures it:

A user story map is a powerful tool that enable an agile team to groom their product backlog and plan the product releases more effectively. A user story map captures the journey a customer takes with the product including activities and tasks they perform with the system. Creating a story map collaboratively ensures team members are on the same page from the start of the project through to ongoing development of new releases.

Instead of casting assumptions about how the customer will use the application, the team develops a dialogue or story from the viewpoint of the customer and how they will be using the product. The idea is to create an experience that is seamless, easy to use, and that can be navigated easily. The user story format should be captured in a simple to understand format:

 

"As a [type of user], I want to [action] so that [benefit]."

By framing up the user journey in these terms, the focus shifts from writing about features to discussing them. Through user story mapping, teams can ensure that the customer journey is personalized and that their story gets told.  

 

Roadblocks to Successful User Story Mapping

Every software project starts with a vision and a roadmap on how to build a product that users love. But somehow along the way it’s easy to mistake the forest for the trees. Development teams (and customers!) often get tripped up around understanding exactly what the application is supposed to accomplish. Feature bloat can easily take over and before long the project has become bogged down. There are a couple major roadblocks that can prevent user story mapping success. 

 

01 You’re working with complex queries and reports.

With SQL you can build one script that retrieves and presents your data. NoSQL doesn’t support relations between data types. Running queries in NoSQL is doable, but much slower.

The lesson here is that developers should focus on the “big picture” of an application rather than product features. Keep continually in mind exactly what it is this app is intended to accomplish. Agile development always tries to begin with what you know but it never should sacrifice the big picture for the small parts (features).  

02 You have a high transaction application.

In the business of writing code and building applications, it’s easy to forget what we’re doing and focus on the software instead of the business outcomes. One of the insightful stats in Paton’s book is that for any software project:

  • Only 20% will succeed in making a big impact
  • 60% have little or no impact
  • 20% will fail; releasing it will actually hurt the customer

The point here is that it’s easy to get stuck in discussions about technical features, architecture, and other minutiae without a clear path to outcomes. Unfortunately, a lot of money and time gets wasted in the software industry when well-intentioned teams build features that no one ever uses. The key here is to avoid the tragedy of the flat backlog – which happens when future features become a laundry list of “stuff to do.” Avoid this at all cost by adopting user story mapping, even if you think it’s too late. 

 

Never too Late to Adopt User Story Mapping

Maybe you’ve heard the term “Frankenstein application.” It basically the not so glamorous adage that has been assigned to an application with a mishmash of disparate and cumbersome features. Like the famous monster of the cinematic screen, some apps you’ve used probably were scary hard to understand. The application likely had unnecessary add-ons that didn’t have rhyme or reason. So, what happens if you happen to be on a team that has unwittingly built a “Frankenstein.” Is there hope?

Fortunately, yes, there is a way to course correct. The first thing to do is to stop and ask your “Why” and rediscover what are the most basic scenarios that you’re trying to provide to the end user.  

For example, you may have created an application to pay your cell phone bill. But somehow along the way, the app became a potpourri of other features like rebates, store locator, or quote engine for the best mobile deals.

Keep the big picture in mind; the most important thing is for the customer to pay their bills. Period. Staying deliberately focused on the customer journey is the most important way to avoid “feature bloat.” Focus on the big picture and make the main thing the main thing.  

5 Steps to Adopting User Story Mapping

So, how does user story mapping actually work in practice? Before jumping in, let’s reinforce the “why” by reflecting again on Jeff Paton’s famous quote: Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.


Our goal as software developers – and this is our mindset at Integrant – is to build powerful and elegant solutions that help our clients change the world. Let’s break down into 5 discrete steps what is required to adopt user story mapping successfully and how to create elegant applications that users love. 

 

01 Frame Your Idea

Before kicking off your user story map, create a short product or feature brief to frame and contain what you map. Think of this as the big story. Ask yourself the following key questions:

  • What? Here you name the product, or feature to add to a product, or identify the problem you’d like to solve.
  • Who? Here you identify the different types of users who will use the product, and the customers who will buy it. For each user, choose the benefit they get from using the product.
  • Why? Describes the benefit your organization gets by building the product or feature. Say what users do and how their use leads to increased revenue or reduced costs. 

 

02 Map the Big Picture

Focus on gathering the whole story. Think “mile wide, inch deep.” The activities and high-level user tasks that tell the whole story form the backbone of your story map. For example, the story below is a typical scenario we all face every morning – bathing and getting ready for our day. 

  • Start with the user type most critical to your product’s success.
  • Imagine a typical day in your user’s life with your new product.
  • Map the steps they take as user tasks from left to right.
  • Identify user activities – groups of tasks that work together to support a common goal. More activities often emerge after you see more of the story.

 

03 Explore

Fill the body of your story map by breaking down larger user tasks into smaller subtasks and user interface details. During this phase you’ll add cards, split one card into two, rewrite cards, and reorganize them. Use this phase to think “blue sky” about all the great possibilities. Use this time to think of everything that could go wrong. Don’t worry if your ideas are “in or out of scope.” You’ll deliberately move things out of scope later. 


  • Play “wouldn’t it be cool if ...” to help think of great product ideas.
  • Look for variations: What else might users of the system have done?
  • Look for exceptions: What could go wrong, and what would the user have to do to recover?
  • Consider other users: What might other types of users do to reach their goals?
  • Add in other product details like:
  1. Description of proposed UI
  2. Business rules
  3. Data elements

 

04 Slice Out Viable Releases

Slice your map into holistic product releases that span the users and use of the product. These slices form an incremental product release roadmap where each iteration is a minimal viable product release. 

  • For each release, name the target outcomes and impact. Outcomes and impact say how this release contributes to the overall goal. In other words, this explains the “big why” that motivates building the product, and how users will behave in a way that helps us reach the goal.
  • For each release, identify product success metrics. Answer the question: “what would we measure to determine if this product was successful?” Ideally, you’ll find specific changes in user’s behavior as they use the product the way your story map imagines. 

 

05 Slice Out a Development Strategy

Slice the first release of your map into three or more delivery phases that allow you and your team to learn fast and avoid risk. Think of the opening, mid, and end-game phases of a chess game. This development strategy will help you release the best product possible in the time constraints you have. 

  • Opening Game: Here you build a “functional walking skeleton” – the simplest possible functional version of the product. As you finish "Opening game" vet the product with users and other stakeholders. Begin validating performance and scalability.
  • Mid Game: Complete all major functionality and make the existing functionality richer and more complete. Continue user testing and leverage feedback to adjust the product. Continue testing performance and scalability.
  • End Game: This is where you refine the product in preparation for release. Continuously assess release readiness based on your release level product goals. Count on unforeseen work to merge during this last stretch of development.

  1. Plan the work necessary to refine stories and workshop stories with developers and testers in order to work through the details and agree on acceptance criteria.
  2. Plan development and testing.
  3. Build and verify parts of the working software.

 

 

Work With Us!

At Integrant, when we sit down with a new or existing client, our overriding purpose is to help them change the world. The result of our engagement will be an elegant, user-friendly application specific to the client’s industry or domain.


But our “why” is always the same. The reason Jeff Paton’s user story mapping system resonates so well with our mission/vision and values is that it assumes from the beginning that software is not about requirements, but about outcomes – ultimately changing the world!


The focus on mapping the big picture of the customer journey, understanding the intent of each user action, and slicing out viable releases while avoiding “flat backlogs” are all values that we hold near and dear at Integrant.


Does your business application suffer from “feature bloat” or is your team dealing with a “Frankenstein app” that has gotten out of control? No matter what the exact situation, we can help you right-size and get back on track.


At Integrant, we’ve been building applications for almost 30 years and know a thing or two about helping our clients bring elegant, user-friendly applications to market. We’re in the business of helping our clients change the world and would love the opportunity to help transform yours. Work with us to adopt a user story mapping approach – either to design and build an app from scratch or else turn around a “flat backlog” – in order to drive value and revenue for your clients.


If you’re looking for a partner to bring the right product to market, then give us a call today. We’ll teach you how to map out your user story, build the application, and grow beyond your wildest dreams.


Subscribe below or contact us to see the impact we can make for you and your business. We can’t wait to get started!

Thanks for subscribing!

footer-img

Integrant’s Vision is to transform the software development lifecycle through predictable results.

Subscribe

To get our newsletter & stay updated

© 2023 Integrant, Inc. All Rights Reserved | Privacy