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.
Was this helpful?
Thanks!
Gergő
3 comments