Story Mapping is an agile technique that finds itself applicable in the delivery of a new product or new feature in an already established product. Created by Jeff Patton, this method allows for a customer to visibly navigate through all of the user tasks it takes to utilize a product from the beginning till the end.
The assignment of these tasks are ordered in such a way that brings the most value to the customer. Nicholas Muldoon, the Co-Founder of Easy Agile, describes this process as “a facilitated, curated conversation” that essentially gathers everyone involved to navigate through it.
A user story mapping can be used whenever you need to create understanding of the future releases of your product while simultaneously maintaining the current state of the product vision.
The process of the agile user story map is most beneficial for agile teams. It is a useful tool in agile planning that assists in development and allows for the team to be able to receptively respond to change.
When developing story maps, an agile team would take into consideration of the Agile Manifesto values that communicate the importance of collaborating with a customer in place of the negotiation of a contract and responding to change instead of following a plan.
These values creates the environment for the team to maintain flexibility as well as prioritizing the customer journey for a viable product.
Flat Product Backlog vs Story Mapping
Flat product backlog is one of the most common tactics utilized in agile software development. It is essentially developed as a “to-do” list of things to cross off that will essentially bring value for a customer. It is designed with a top-down approach in mind which places the most valuable items at the top of the list with the least valuable items at the bottom.
This allows for things to be crossed off in order of priority. This differs from story mapping as story mapping contextualizes each list item into a bigger portion of the development task. Story mapping established the entire picture of a product while flat backlog simply does not.
Flat backlog makes it difficult for a product manager to make a determination of whether or not their team identified the necessary user stories. It also doesn’t give product managers the ability to explain how the system works and what it does.
User story maps creates a visual that allows for the agile development team to focus on the customer outcomes that are desirable. Agile teams are able to identify and execute a variety of features based on how each customer responds as well as track progression. This also produces less waste with improved outcomes for the entire product in contrast to flat backlog.
Creating User Stories
One way to begin creating a user story would be to define what your goals are. The best way to initially format the user story would be to think about product interactions from this perspective: As a [type of user], I want to [action] so that [benefit].
A few user story examples of this would be:
- As a visitor of this site, I can type the color of the product I want in the search bar so that I can find what I’m looking for.
- As a returning visitor, I can have my previous history saved so that I can return to what I was looking for.
According to the Jeff Patton, creating the user map in done is six steps:
- Establish your idea
- Create the big picture
- Develop a release strategy
- Develop a learning strategy
- Have a development strategy
It is important to first approach developing a backbone in your story to describe high-level tasks or high-level features from beginning to end. These steps creates the building block to producing a collaborative approach for the story map.
The walking skeleton is in essence the core of a user story and one of many parts that creates the entire story map. It is utilized to give a visual representation and descriptor of essential components that are required to release a valuable product. They are stories provide a user experience with tasks that they can perform throughout the product. This particular set of stories allow for the product to be functional at the bare minimum and are interchangeably known as minimum marketable features. Combining the walking skeleton with other user persona type like the backbone and other stories underneath the walking skeleton, you will then have a full story map.
Creating and assessing the quality of a user story in the initial story map is traditionally done through the INVEST criteria. If there is any part of a story that does not meet any of the criteria, it would be important for the story to either be readjusted or reworded.
Independent – every user story should represent independent business values so that they can deliver those values if they were to be released alone.
Negotiate – The method to achieving each goal should have the ability to being negotiable. Regardless of who is involved in the transaction. This could be between the product owner and the customer, or the product owner and the development team. Stakeholders can also find themselves involved in the negotiation process.
Valuable – Each story should represent some form of value to any specific user type.
Estimate – There must be enough information readily available so that the story could be appropriately sized so that the plan can be properly implemented and there is commitment to completion.
Small – Small stories are preferable for user stories so that they are able to be completed within a single sprint.
Testable – The entire team should be able to utilize precision as a means of verifying the completion of a user story.
3 C’s in User Stories
Having an established approach in creating user stories is beneficial to this agile format. The most common approach is the Three C’s approach. This approach was coined by Ron Jeffries in Extreme Program Installed. The Three C’s specified are card, conversation and confirmation. Jeff Patton also discusses this approach in more detail at Flowcon.
The card portion of the Three C’s approach is essentially having a written description of a story that is utilized to plan. Having the ideas from your entire team written on a card, sticky note, or even a whiteboard launches the ability to put everything into a draft.
This is a collaborative exercise that is implemented by throwing out any information that comes to mind, including potential titles of the stories themselves. Be mindful that stories should be written in a manner that creates a statement of value and intent. This is known as user voice.
The goal of the conversation process is to discuss ideas and work together to develop solutions. It is important in this process to ask the who, what and why of a story. It is the responsibility of the product owner to answer these questions in the planning process. This is to ensure that the team as a common goal.
Confirming a story map gives the technical information of a story as well as confirms that the execution of a particular story is upholding its intended value. Having a unified team consensus on what is appropriate to build should also be recorded.
Advantages and Mistakes in Agile Story Mapping
There are direct advantages of story mapping in the agile processes. Story maps allows for everyone in the development team to understand the entire construct of the application, especially the parts that finds itself to being the most difficult. This process also allows for your team to have a complete visual of the product, solving a major complaint that exists in agile teams. Teams are able to see where each part fits into the entire system.
One additional benefits of user stories is that it assists teams in identifying what areas to develop first. If it appears when developing a website that the user journey of a website finds itself focused on a specific section of the about me page more often than other web pages, then it would be most beneficial to begin building upon it first.
It is important for product managers to be mindful of common mistakes that occur through mapping.
A common mistake that occurs in utilizing user story maps is that teams can find themselves working with a customer that is not familiar with their product. It is vital to have someone familiar so that you will have more certainty in the value that they provide when navigating.
Not keeping the story map visible to your agile team is another mistake that appears in development. The story map is a reminder for the entire picture of an application. If it is not seen clearly and often by the team, a lot of goals can become lost in the process.
Tools for creating agile story map
Finding the right tools is vital to creating an agile story map. Jira is considered one of the most useful tools for developing the map. Here is a list of mapping programs that integrate with Jira:
1. Easy Agile