Transforming a software project from an idea into a tangible and viable product requires a common vision that is shared by all team members. That common vision must then be translated into a product backlog, which includes a list of features that will help formulate a clear and detailed to-do list.
That’s the point at which many software projects start to falter. Failing to thoughtfully map out what users really need before building a product can result in an inefficient development process that delivers a less-than-ideal solution. To avoid this scenario, there are a few vital questions to consider as a project moves from the ideation stage to the production phase:
- How should we prioritize a backlog in order to deliver only what is needed?
- How can we ensure that all critical pieces are in place?
- What is the most effective way to communicate the vision with the team?
At BIT Studios, we believe that every software project should utilize story mapping to help answer those questions and foster effective communication.
It’s best to begin with a basic story map and update it as you progress through your minimum viable product and beyond.
Let’s take a look at how using story mapping can save you time and money while ensuring a successful product launch.
What is a story map, and why is it important for software development enterprises and startups?
A story map is a visual representation of your project that helps stakeholders learn about a product’s features.
By identifying features and organizing them into workflows, you can better understand the details of the product and gain insights into its functional dependencies.
The concept of organizing important product elements into a story map originated in K-12 school and university environments. In education, story maps are used to help individuals or groups more effectively comprehend information by breaking it down into categories. It can be applied in a similar manner, and offers similar benefits, in the software development field.
According to academic research, story mapping helps:
- Improve team comprehension
- Identify gaps
- Efficiently organize your vision
A backlog or list of to-do items is flat and may confuse your team. On many software development projects, only the product owner is able to fully understand the prioritization and work order; the team is unable to see how backlog items are interconnected. And because the backlog provides only a one-dimensional view that doesn’t show potential gaps, even the product owner may miss key elements.
Story mapping involves placing stories along two independent dimensions:
- The horizontal axis arranges features in order of how users navigate through the system.
- The vertical axis represents the necessity of a particular functionality to achieve the result. This means that more important functionalities appear ahead of less important functionalities (from a user flow perspective).
Arranging a story map in this manner and grouping workflows provides a representation of the raw, minimally-viable version of the product.
An example of what a user story board looks like:
Story maps make it easier to visually explain user stories and the idea behind your product.
How to create a minimum viable product with an efficient user interface at a low cost
The concept of the minimum viable product (typically referred to as the MVP) is one of the most important ideas in software development. The idea is to deliver a product with the minimum number of features necessary to function properly and satisfy users’ needs.
This approach allows developers to receive feedback from potential users and customers as early in the development process as possible, which helps them avoid spending time and money producing deliverables that customers don’t need.
Story mapping is an extremely helpful technique in this regard, as it helps developers organize product features and select the ones that are most effective and most important to users.
Proving new product concepts with an MVP is essential because your idea should be simple enough to produce something tangible within two to three months. If your idea is too complicated, it may require significant effort and investment just to determine whether it’s even worth pursuing.
The very first step in creating an MVP is understanding the key assumptions about the customer’s interaction with your planned software product.
This means that you should define the problem your product is going to solve. It should be a real issue for the customers, and not just your assumption.
How do you determine that? Well, you should first test your hypothesis through market research or interviews with potential customers. You should be able to answer a few questions during this testing phase:
- What makes you believe that customers experience a particular problem?
- Are there enough customers with this problem to recover your investment in the solution?
- Why do you think customers are struggling with this problem, and why do they want to resolve it?
All these questions should be asked and answered in order to prove the concept, and you should only proceed to the next step once you’re confident that proof has been established.
Once you’ve proved your concept, you need to create a step-by-step process for building a product that solves the problem you’ve identified.
It’s important to keep in mind that you should only start story mapping after you have a concept that you believe has been sufficiently proven. That’s because if nobody knows what the end goal of the project is, it will be impossible to build a successful product. However, once you’re confident that you’ve identified both a real problem and an effective solution, a story map will be a valuable tool.
Key stakeholders often say that a certain feature is necessary without having really tested it against actual market needs. You’ve probably heard something like: “We can use this apartment renting functionality for business apartments, private apartments, and car rentals–in a nutshell, they’re the same.”
Story mapping continues to be helpful later in the process, when it comes time to prioritize your backlog. Without mapping your stories as end-to-end processes, you may end up delivering less important functionalities first.
What are the benefits of story mapping?
Story mapping has become a widely-adopted methodology because it provides a bird’s eye view of the software application experience. Using this approach may also have several side benefits because of the improved clarity and vision it facilitates.
The biggest part of the application is often useless!
According to a Standish Group report titled “Chaos,” 45 percent of applications built by businesses are never used by customers. Similarly, 19 percent of applications are used only occasionally. More interestingly, only 7 percent of features are always used, while only 20 percent are used often.
We can infer from these findings that most apps are built with too many features. In most cases, only 20 percent of existing features were necessary to satisfy users’ needs.
You can gain a number of key advantages by focusing on only building that 20 percent of functionality.
Lower costs, higher returns
Software development involves experimenting with multiple ideas, and not every idea is going to work. But spending less money prior to proving your concept will make you that much more successful in the end; after all, you may need to make multiple attempts before one is successful.
Any commercial idea requires a return on investment. The less money you spend at the product development stage, the bigger the potential return. By mapping your minimum viable functionality, you may potentially spend only 20%-30% of the initial budget.
Clearer user interface (UI)
Taking into account the primary user flows, the user interface may become clearer because you already know which function a potential user may need next. Providing only the necessary features means that only a few action items are required per screen; thus, the user journey is simplified and becomes more coherent.
How to create your own story map?
Creating a story map is similar to telling someone a story. You have to describe a sequence of events from beginning to end. Some stories may have many details, while others may only be a small set of facts.
Tell a story
It may be you or the subject matter expert who tells the story and goes through the stated problem. As you go through it, you should create an action list. At first, you don’t need to do any sequencing — just write the action items down.
The first iteration should not be long, and it’s OK if you miss something at this step. Chances are you’ll realize it later.
Some people prefer to use sticky notes and place them on the wall, while others use a notebook or software application. Choose the approach that’s most comfortable for you and your team.
Sometimes, your subject area may be quite complex, and several experts are needed to identify and explain action items. It’s alright to go through the sequence with a multitude of people and then simply remove any duplicates.
Group action items into activities
Once a list of action items has been created, it can be divided into activities. An activity is a type of story which unites several actions. For example: “As a store owner, I want to process customer orders with various means of payment.”
For story mapping purposes, you can say: “Process payment.” This activity may then contain multiple actions, such as integrating card processing terminals, collecting payment data, and charging a customer.
If you’re acquainted with the concept of user stories and tasks (as often used in agile development) you can roughly connect activities with both user stories and tasks.
Again, as with the first iteration, you may create incorrect groupings. Getting them right often requires several iterations. That’s why people use sticky notes–they’re fast and easy to rearrange.
At this point, it’s also fine if the groups are unequal. Some may consist of only one activity while others have dozens. You’ll improve the map after several iterations.
Check for consistency
Now it’s time to see if you can build a sequence of action items with no gaps. The best approach is to have another person to go through your map and ask you questions like: “How did you get to this point, if you don’t have X and Y?”
You can also do this exercise on your own, but it’s always good to check the process with the help of a different actor.
For example, if you build the development process from a buyer’s perspective, make sure to also check it from the seller’s perspective. After, you may want to regroup your action items, add new elements, or rearrange the workflow.
Now it’s time to prioritize your action items. On the very top of the map, you should have activities that are at the core of your system. They are absolute “musts” in order to solve the stated problem.
There is one particular approach which often proves useful at this point in the process: prioritize items as “must,” “should,” and “nice to have.” Must goes at the top, while “nice to have” goes at the bottom.
Define your minimum product
Once you have a demonstrative representation of your backlog, you should be able to draw a line and be left with only the items necessary for your minimal product. It’s OK if this line isn’t straight, because in some of the groups you may have more items to finish than in others.
Update the map regularly
To ensure that your backlog is groomed, your story map should be updated from time to time. You can do so once per iteration, but don’t forget that changes are intrinsic to software development projects and your vision will become clearer with each iteration.
As such, you may want to rearrange or regroup items. In any case, your story map will help you see the whole picture more clearly and improve the general understanding of the project among your team.
Story mapping is a time-tested and proven approach to achieving your software development goals in a viable manner. It’s particularly useful when you want to:
- Proof your concept within a couple of months in a cost-efficient way.
- Prioritize your backlog to deliver end-to-end processes as soon as possible.
- Minimize functionality in big projects.