Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Two-level vs three-level story mapping with JIRA

Designing a product with user story mapping is becoming more and more popular. There is no question that visual backlogs build shared understanding among team members, boost the ideation process, and help involve non-technical members into the process.

Thanks to many online tools, teams don't need to build story maps on the office wall. Virtual sticky notes and virtual story maps let agile teams work remotely in real-time, then process the backlog to a project management tool such as JIRA.

The business/project need can be very different, and the procedure may result in different usage of the story mapping method. One of the main differences is planning a product on either a two-level or three-level story map. Read further and find out which method fits the best for your project.


3 Benefits of using three-level story mapping

Let me start with the three-level story mapping because this is how Jeff Patton – known as the father of user story mapping – made up the method. Story mapping on three levels gives an opportunity to arrange user stories under epics and under the narrative flow. We call the first two levels of the story map “product backbone” or “walking skeleton”. This layout of a product backlog delivers many opportunities for a powerful design process. I’ve summarized the top 3 benefits:

1. Map the narrative flow to understand the problem

First, building the narrative flow and telling the story gives an unbeatable opportunity to understand a user. Framing a problem and finding a solution for that can be easy, but you need to check whether or not the product meets with the users' needs. So, start ideating about user goals, that they would attempt while using the product. You can easily turn these groups into epics and sync to the JIRA project.


Then find out the steps the user takes to reach her/his goal. Inserting an “AND” word between two steps helps to build a natural flow. The product backbone can work as a visual aid when collecting the user stories on a brainstorming session. So collecting the user steps supports ideation, but they aren’t really important during the dev process. That's why you don't need to integrate them into JIRA projects.

2. Nice spot to check the completeness

Poor planning often results in a failed (or at least broken) product. That’s why you need to double check the backlog before prioritizing or versioning. The story map gives two control opportunities. The first solution is related to the narrative flow. Retell the story, searching for missing steps or a broken journey.

Let me tell a story: an agile team wanted to develop a brand new software for cash machines. They wrote all the user stories about inserting the card, entering pin-code, entering the menu, withdrawing the money, etc... but something was missing. Fortunately, they found the missing part at the end of the brainstorming session. Do you see what is missing?


Yes, they forget to “give the bank card back” :-)

You can check not only the narrative flow but the user stories. If there are no user stories written under a user step, then there is no solution to take that step in the journey. So you need to write at least one user story under each user step.

3. Involve non-technical members

Flat backlogs are uninterpretable for non-technical members. You won’t dig out all the useful ideas from the stakeholders during ideation. On the other hand, customers, support team members, customer service reps and so on can provide vital feedback and ideas. Involving them in the product is easier on an intuitive and visual backlog.

They can jump into the project in a few minutes because understanding the user goals, the narrative flow, and the stories is a no-brainer. To be honest, two-level story maps can have this benefit too, but thinking in narrative flow is much more inspiring.

When to use two-level story maps

Looking for a lightweight solution to visualize the backlog? Then the two-level story map is for you. Group user stories around main features or epics, then push them to a JIRA project. You'll find easy-to-use plugins and also external tools to manage the ideation process and build a story map. This solution suits:

  • smaller projects, when the narrative flow is too short or uninterpretable
  • developing increments for a running product
  • when you can't build the narrative flow around a user journey, e.g. developing backend and frontend parts of the product
  • high-level planning, when epics are located on the second level and user stories will be created in JIRA


Two-level story maps still have the opportunity to express priority with vertical order, which is a good starting point for versioning later on. It's still an effective way to discuss the product with non-technical stakeholders and groom the backlog. In addition, integrating the two-level story map to the JIRA project gives you a nice spot to track the dev process from a bird’s-eye view.

Story mapping for better productivity

To sum up, no matter which tool you choose, user story mapping delivers you awesome opportunities to boost the planning process. It visualizes the product backlog, so it's tremendously easy to see the relationships and dependencies between epics and user stories. Non-technical members can be involved too. In addition to the improved planning process, the backlog grooming will be easier than ever. Choose the two-level story mapping if you're looking for a lightweight solution. But if you would understand the users' motivation and the journey you'd be better switching to a three-level story map. So you can massively support the product ideation.

I used StoriesOnBoard as story mapping software for JIRA, to capture screenshots.



Log in or Sign up to comment
Bogdan Gorka
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 6, 2019

Thanks for the article! I am always happy when I find a tool that helps Jira to be more visual. For those interested in the story mapping method, it is also worth looking at:

1. How this works in 5 steps:

2. Examples in the story mapping system:

Like Gergő likes this
Sequoia McDowell May 21, 2019

Thought provoking post! A few questions:

  1. How is a two-level workflow different than simply having separate projects? "Frontend" doesn't sound like an epic, it sounds like a team. Or is "frontend" a finite block of work? Otherwise, do you have a column that goes on forever?
  2. "teams don't need to build story maps on the office wall." but you do need a tool outside Jira/Atlassian (such as stickies on a wall)? I mean to say, Jira can't do this for you, correct?
  3. Is the workflow described herein specifically related to StoriesOnBoard, or is there another tool (besides stickies on a wall) that also does this in concert with Jira?
Henri Seymour _Easy Agile_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
May 21, 2019

@Sequoia McDowell, it is true that Jira doesn't natively support story mapping. 

In order to allow customers to "take it off the wall" and do away with stickies on a wall, we created Easy Agile User Story Maps so that Jira users could create story maps within Jira. It integrates with Jira with no setup so the issues you create and the epics, sprints or versions you add them to are saved in your Jira instance. 

We'd be happy to run through a demo with you and we can answer any questions you have about story mapping if you want to learn more or try it with your team! 

Like Sequoia McDowell likes this
AUG Leaders

Atlassian Community Events