Relationship between issues, teams, sprints, releases

[Derrick Cawthon]

I am coming from Azure DevOps and trying to understand the data relationship (and flow) in JIRA Server for issues/teams/sprints and releases. 

For example the below image I created shows how data moves at high level through Azure DevOps relating to work items (issues), organizations, projects, teams, sprints and releases (pipelines). Is there something similar for JIRA?

[Nic Brough -Adaptavist-]

Your diagram is not fully supported by Jira Software in the way you'd like.  The two big points here are:

• Jira Software's hierarchy is Epic -> Story -> Subtask.  This represents the Story and Feature layers in your diagram (sub-tasks are not in your diagram, but would be right at the bottom as parts of stories if they were)
• Jira Software has a bit of a historic problem in that the original writers of it made a mistake in calling Jira Epics, Epics.  The world quickly moved to a place where the hierarchy Is Epic -> Feature -> Story -> Sub-task, but Jira did not change.  Annoyingly, renaming Epic to Feature is a bit broken - it appears to work ok in most places in Jira, but causes problems in some apps, and the UI (What should be renamed as a "Feature Report" for example, remains an "Epic Report")

To get your Epic -> Feature -> Story hierarchy, you need apps to provide the layer(s) above Feature (Jira Epic).  This means heading for Jira Align, Structure, Big Picture, Easy Agile or Advanced Roadmaps (there may be more, those are just the ones I've worked with)

[caglad]

Here is one way to set it up.

Team A can be your "project 1" lets call it MS Word

Team B can be your "project" 2 lets call it MS Excel

You can also create a user group - this can be made up of people in one team

Each Team Can have an Epic - In our world we use the name of the release "MS Word V 2.15"

Each Epic can then have a Task Issue type, Bug issue type, Enhancement issue type etc (these are standard issue types)

Each Standard issue type can have subtasks for that issue type to be completed.

Then each epic, standard issue type of issues and subtasks can have a fix version (which matches the name of the release above in EPIC - we do this because the epic reporting will only capture standard issue types and will not include subtasks.

You could also have multiple fix versions to break up the Epic - in our world, we like to keep it a one to one releationship

You can then create a sprint (under the project) and take part or all of the issues in the epic