Jira introduces so-called next-gen projects. They don't support versions. And they won't. So it's much more critical now to have a feature to map SoB releases to something else in Jira (Sprints, for example).

https://community.atlassian.com/t5/Jira-Software-questions/Versions-in-Next-Gen-Project/qaq-p/939996

It's disappointing that it's been over two years and this Feature has not been provided

This is a very important feature

I would prefer a more flexible mapping mechanism, where I can choose, which JIRA concept (e.g. components, epics, tasks, subtasks...) I want to link to which concept in StoriesOnBoard (e.g. blue, yellow, white cards, releases)

I have just reluctantly ruled out Stories on Board because it cannot support the epic/story hierarchy. I went with Feature Map instead. Would love to look at Stories on Board again if this gets added.

For me, the blue card is not a feature I'd use.
The yellow cards will be epics.
The white cards are stories.
The releases are sprints.

I could also imagine:
the blue ones being epics,
the yellow ones being stories,
the white ones being tasks.
This, however, would be to specific for my target audience.

The new improved integration with Jira is a step in the right direction, but it only allows us to assign the same values to *all* issues in Jira. Additionally, it only works for new features. And finally, it offers no mapping of StoriesOnBoard values to Jira except as labels. These limitation makes the feature not very useful.

For example, we can now a static value or vlues to Jira's "Fix Version/s" field. Say we have five Versions in Jira "Version 1", "Version 2" etc to "Version 5". The current integration requires that we choose one or more of these values and assign them to all cards ported to Jira! If you have multiple Releases in StoriesOnBoard, then all cards under all Releases get assigned the value "Version 1" in Jira!

What we really need is the following:

* Allow us to map from *any* supported field in StoriesOnBoard to *any* supported field in Jira.
* Allow those values to update every time the cards are pushed to Jira, not just the first time.

Here's the detail of how you could make it work:

1. Set up the mapping in StoriesOnBoard preferences. On the left, choose from any supported field in StoriesOnBoard, and on the right, map to any supported field in Jira. Right now in StoriesOnBoard, you support the fields
Activity,task, release, colorLabel, activityColorLabel, taskColorLabel, storyMap. In Jira, you support Fix Version/s, Priority, Labels, Component, Epic, Link.
2. When you map, see if the value in StoryOnBoard exists in Jira. If it does, then assign it to the Jira issue. If it doesn't, create it in Jira, then assign it.

If you could expand the fields you support, that would be helpful also. For example, on the Jira side, Sprint and Type, and on the StoriesOnBoard side, the type of story (Epic, Task, or Story) to map to the Type field in Jira. By implementing the Type mapping, you'd take care of a big part of the request people have been making.

That's it. Could you implement that? It would be much more flexible and useful.

I suggest to make this quite flexible, for example, in my case, managing many products, I'd like to use story mapping for not real user story map, but for visualising big picture among all my products. Therefore, blue cards might be something like "themes" or "ideas", then yellow as "grand epics" and white as "epics". Users need to customize this to get full synchronisation experience

A complete Sync with Jira would be helpfull. As well as the visualizaton of Themes (Blue Card) with Epics and Versions with Sprints.

As mentioned below the sync is a very important feature, otherwise there is a lot of manual work / sync to do. This normally leads to not using a tool like SOB.

i'd recommend that the mapping should be pretty flexible. a blue card would be a theme for me.
Epics related to the blue card but one blue card could contain 3 epics. They would be orianted on a release ( epic XYfeature MVP, epic XYfeature step 2, etc)

Yes, this is very important. The integration isn't really useful without this feature. It's too hard to work in Jira if the releases (the horizontal levels in StoriesOnBoard) and epics/features (the vertical levels) aren't captured in Jira.

was disappointed to see blue & yellow cards are not exported to JIRA.
Would be great to have the option to map these to epic/theme/labels etc in JIRA.

Since the fundamentals of story mapping involve grouping white cards (story details) under a yellow card (the story), and yellow cards (stories) must be grouped according to the blue card (epics), this absolutely has to be part of storiesonboard.com functionality. It doesn't work to make the white cards the epics and stories, that makes connecting our story map to JIRA useless.

I agree with Jeff, but for SoB they should give the option for the user to choose for themselves per board what should be exported and where. Maybe you want the whites ones to be epics, some are on the story level. I prefer the releases to be epics, whereas some would use the version in Jira. You will not be able to satisfy most users with a strict approach.

At least we should be able to push / import epics between JIRA and the story board...

I disagree with many of the comments listed here. I believe epics should correspond with a release theme in SOB. Epics are sometimes used as labels by people who use jira but that doesn't make sense.

It would be great (at minimum) if you could map epics/features to tags or fields in Jira. That would save a lot of work.

@john: wouldn't the correct structure be more like this:

Goals: does these exist as an entity in SoB?

User Activities -> Epics

User Tasks -> <no Jira equivalent>

User Stories -> Stories (Jira Issue of type "Story")

And also map "Release" in SoB to "Version" in Jira..!
Release -> Version

I tried to map (white) SoB-cards to JIRA Epics. However throws an error since the required field "epic_name" (in JIRA) is currenty not pushed from SoB. SoB support suggests to make Epic_name optional (versus required) in JIRA. This would no longer block synching. Unfortunately, this field seems to be configurable in JIRA. See https://confluence.atlassian.com/agile/jira-agile-administrator-s-guide/jira-agile-jira-configuration Has anyone some solution?