All you need to know about Jira structure sync

Introducing the Jira structure sync feature is a perfect opportunity to summarize the benefits of using the integration.

No matter, if you have an integrated backlog, planning in Jira is annoying, and poor planning leads to a failed product. So planning on a visual backlog is essential for a product owner.

But this is not always easy…

Product owners work under constant time pressure. That’s why they need to choose a planning method (and tool) that helps them avoid unnecessary extra work. For example: collecting user stories on a whiteboard, then doing the same thing again in an issue tracker could be a waste of time.

Follow us to learn about an integrated, agile solution for creating and managing the product backlog and also effectively executing development, using Jira and StoriesOnBoard.

By the end of this article, you will learn about the benefits and quick wins you can achieve by synchronizing your product log and Jira.

Jira structure sync for connecting the product vision to the development

The high-level planning begins with gathering product goals/epics and creating the narrative flow of the user journey. This is the starting point of discovering 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.

In addition, by synching the hierarchy and the dev process, you can change the scope of the product. StoriesOnBoard offers several options to integrate the story map into your Jira project.

Two-level and one-level Jira 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 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 option to synchronize only user stories. StoriesOnBoard integration fits all product needs. So you can choose the export issue type for the pushed cards such as user story, task, or bug. In addition, when designing a large product, you can export user story maps to Jira epics and use the story map for high-level design.

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 back and forth on the other side. To save all the crucial details from the product discovery session, you should create specs for the epics at the brainstorming session. All the information you record goes to Jira, and you will have the chance to update it when it’s necessary.

Best practices:

• Provide brief descriptions during the brainstorming session, and if necessary, elaborate on them later.
• Use the same template to finalize 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 do switch between one- and two-level Jira structure syncs?

If you use StoriesOnBoard with one-level Jira structure 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 v, 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 them 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 v structure sync, where the source hierarchy comes from v 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 Jira 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 Jira 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 Jira 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.

Time-saving opportunities

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 results of product discovery or brainstorming are user stories that 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 as they arise. Product design is not a waste of time. 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 and slicing user stories into releases or versions is annoying in a flat backlog. The user story map provides the best overview of the product. Sorting backlog items into releases is easy and intuitive with drag-and-drop functionality. In addition, priority-setting, such as MoSCoW categories, provides an effective idea base. 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, and export them to v. Efforts are summarized release by release, providing a good way to calculate the capacity of the development team and forecast the development process.

Keep an eye on the progress

Although the visual backlog provides an intuitive overview of the product, you can enhance it with 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. In addition, with just a few clicks you can produce impressive but lightweight status reports, which is extremely 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 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 manage product backlog and to involve non-technical team members. Thanks to a wide range of structure synchronization options, agile planning no longer means duplicated work.

Related Contents

Setting up synchronization with JIRA

Setting up JIRA structure sync

Visit website: StoriesOnBoard – Story Mapping Software For JIRA