Introducing the brand new JIRA structure sync feature is a perfect occasion, to sum up, all the benefits of using the integration. Whether you have an integrated backlog or not, planning in JIRA is annoying, and poor planning leads to a failed product. So planning on a visual backlog is vital for a product owner.
That’s, however, not always so easy….
Product owners suffer from lack of time, and that’s the reason they need to choose a planning method (and tool) that helps to avoid duplicated work. For example, collecting user stories on a whiteboard, then redoing it in an issue tracker could be time-wasting.
Follow us to learn about an integrated, agile solution for designing, managing the product backlog and executing development in a most effective way, using JIRA and StoriesOnBoard. At the end of the article, you’ll learn all the awesome benefits and quick wins achieved by synchronizing the product backlog to JIRA.
JIRA structure sync for connecting the product vision to development
The high-level planning begins with collecting product goals/epics and telling the narrative flow of the user journey. It’s
startingpoint of discovering all the user stories. The top-level and second-level cards have a secondary benefit. They provide a wide range for setting a different scope for the product.
Moreover, you can retain the opportunity to vary the product scope by synchronizing the hierarchy to the dev process. StoriesOnBoard offers several options for integrating the story map to your JIRA project.
Two-level and one-level structure sync
In most cases the top-level cards point to user/product goals. We call these cards epics on a story map too. Assigning top-level cards to JIRA epics works properly with small and midsize backlogs. Use second-level cards for a detailed description of the journey. It is useful to focus on what steps the user takes to reach the related goal.
Building the narrative flow provides a perfect way to discover all the user stories. In this case, second-level cards support the product discovery, and it’s not necessary to use them during the development.
In some cases – especially on larger backlogs – using the second-level cards offers a better grouping opportunity. Assign second-level cards to JIRA epics when the previous method would result in huge epics. In addition, the top-level cards can represent a bigger part of a product, e.g.: backend parts, frontend parts or different journeys, e.g.: webshop buyer, web shop administrator. In these backlogs, you should collect epics on the second level. It provides a nice, neat way to set different scopes or assign parts to different teams.
For the rest of the product cases, you still have the opportunity to synchronize user stories only. StoriesOnBoard integration fits all product needs so you can choose the export issue type for the pushed cards such
How to create epics in StoriesOnBoard?
You can easily create epics during the product design process. No matter which two-level sync method you choose, the tools synchronize epic details too. Changes in the description create changes on the other side back and forth. To save all the crucial details from the product discovery session, you should create specs for the epics at the brainstorming session. All the noted info goes to JIRA, and you will have the chance to update it when it’s necessary. Best practices:
- keep the descriptions short at the brainstorming session, and detail it later if necessary
- use the same template for finalizing epic details to make them easy-to-read
- StoriesOnBoard can export details with a direct link to the story map, which is useful when you wrote valuable info such as comments on the card
How to switch between one- and two-level structure syncs?
If you use StoriesOnBoard with one-level JIRA sync, you can decide to switch to two-level sync. Don’t be afraid! You can switch back and forth between sync methods without data loss. By setting up the two-level JIRA synchronization you can select which story map level you would assign to JIRA epics.
The second question you have to answer is which structure you would use as the “source of the truth”. You can originate an epic-user story structure from JIRA, and you can also set up the story map’s hierarchy in JIRA. As a result, the integration exports the epics from the source structure and rebuilds it on the other site. In addition, during the synchronization the user stories will be arranged in the newly created structure.
Cases of different JIRA and story map structure syncs
1. Switching from one-level sync to two-level structure sync, where the source hierarchy comes from JIRA and top-level cards are used as epics
JIRA epics are added to the top level of the story map, and all the cards are arranged under the new epics. The JIRA project remains untouched.
2. Switching from one-level sync to two-level structure sync, where the source hierarchy comes from StoriesOnBoard and top-level cards are used as epics
StoriesOnBoard epics are added to the JIRA project and user stories are arranged under the new epics. The user story map in StoriesOnBoard remains untouched
3. Switching from one-level sync to two-level structure sync, where the source hierarchy comes from JIRA and second-level cards are used as epics
JIRA epics are added below an empty top-level card on the story map and all the user stories move under the new epics. The JIRA project remains untouched.
4. Switching from one-level sync to two-level structure sync, where the source hierarchy comes from StoriesOnBoard and second-level cards are used as epics
Second-level cards of the story maps are added to JIRA project as epics and user stories move under the new epics. The user story map in StoriesOnBoard remains untouched.
To avoid data loss, empty epics remain in the backlog, so you have the chance to save all valuable information. I recommend merging descriptions onto one epic card and removing the older one.
It’s not just about exporting hierarchy to JIRA. The project comes alive as it fills with valuable thoughts and user stories. Moreover, being agile means you plan and also work in iterations. StoriesOnBoard delivers all the necessary sync features to achieve that.
Synchronizing user stories
Let’s talk about the details. The most important outcomes of a product discovery or a brainstorming session are the user stories, which lead to actionable tasks. In order to preserve all the useful ideas of a collaborative planning session, you should write down all the valuable thoughts when they arise. Don’t regret the time taken for product design, StoriesOnBoard synchronizes all user story details to JIRA, such as description, effort, etc. So, you don’t need to write them twice. Keep the description short during the ideation and detail it later. The integration will update user stories back and forth in real-time. So, you won’t miss any added details when managing the backlog in StoriesOnBoard.
The most powerful way to plan iterations
Managing user stories and slicing them into releases or versions is annoying in a flat backlog. A user story map offers the best overview of the product. Arranging backlog items into releases is easy and intuitive with drag and drop. Also, creating prioritization releases such us MoSCoW categories provides an effective pool for ideas. You can deal with this in StoriesOnBoard – separate from JIRA. And when it’s finished, you can send it to JIRA. Thanks to the synchronization, you can create release goals on the story map, which could be exported to JIRA. Efforts are summarized release by release, so it gives a nice opportunity to calculate the dev team’s capacity and forecast the dev process.
Keep your eye on progress made
Although the visual backlog provides an intuitive overview of the product, you can boost it with the status sync. After connecting StoriesOnBoard and JIRA status, you can follow the current iteration on the story map. All the status changes in JIRA update the user story status in StoriesOnBoard, so you don’t have to switch between tools while managing the backlog. Moreover, you can create compelling but lightweight status reports with just a few clicks, which is tremendously useful for a non-technical participant.
The final piece of the puzzle
To sum up: managing all the product owner’s tasks in a flat backlog is ineffective. There is no place to ideate and collect half-baked concepts. Non-technical members struggle with issue trackers. These obstacles can lead to misleading communication, missed deadlines and even to a failed product. Managing product owner tasks, such as ideation, product discovery, backlog management and iteration planning should be separated – but also integrated – from the day-to-day dev work.
StoriesOnBoard provides all the vital tools to deal with product backlog and to involve non-technical team members. Thanks to the wide range of structure sync opportunities, agile planning is not equivalent to duplicated work anymore.
Try is not! Sing into your StoriesOnBoard Workspace
Not yet registered? Try StoriesOnBoard for FREE
Visit website: StoriesOnBoard – Story Mapping Software For JIRA
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?