I suggest you ...

Sync structure of themes/epics/stories with JIRA

"Is it possible within the synchronization of JIRA to set some sort of interface structure where for example the epics are parents of user stories and etc.? Just like the setup in JIRA?

For example on the screen you now see a blue card with date of import, and a yellow card with the number of the user stories that are imported. It would be nice as user to have the ability to link the blue one to for example epics and the yellow one to user stories and the white ones to tasks. Is it possible to have such feature added?


277 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminArpad Tamas (co-founder, StoriesOnBoard) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Ankh commented  ·   ·  Flag as inappropriate

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

  • Jochem commented  ·   ·  Flag as inappropriate

    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)

  • Chris Young commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Lawrence commented  ·   ·  Flag as inappropriate

    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.

  • Michal Polačko commented  ·   ·  Flag as inappropriate

    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

  • Anonymous commented  ·   ·  Flag as inappropriate

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

  • Anonymous commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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)

  • Lawrence commented  ·   ·  Flag as inappropriate

    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.

  • Richard Bate commented  ·   ·  Flag as inappropriate

    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.

  • K Blaine commented  ·   ·  Flag as inappropriate

    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.

  • Jan Tryggvason commented  ·   ·  Flag as inappropriate

    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.

  • jeff commented  ·   ·  Flag as inappropriate

    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.

  • Ed Croft commented  ·   ·  Flag as inappropriate

    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.

  • Rickard Nord commented  ·   ·  Flag as inappropriate

    @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

  • dirk.diddens commented  ·   ·  Flag as inappropriate

    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?

← Previous 1

Feedback and Knowledge Base