Thanks, we'll contact you soon.
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.
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.
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.
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).
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:
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.
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.
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.
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:
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.
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.
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.
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.
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!
Integrant’s Vision is to transform the software development lifecycle through predictable results.