nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Hierarchy. I'm going slightly mad with all otf this.

Jaromir Toke

Hi.
I'm new user so please be forgiving to me. I have spent dozens of hours over articles and Comunity posts to figure out what is ultimate hierachy of issues, versions, releases,
epics, initiatives and when i should use it. Can anyone explain me please, when use what, and what is function of each?

I think, I already understand, more or less, what is story, task, bug and when use it.
But versions, epics, components, releases, initiatives confuse me a lot. What is difference between version and initiative or epic? Initiative is "must have" to use, or is complementary to versions?

Do i have to add Stories from Backlog to Spints, since, apart from a general description of the client's needs, they do not fulfill another function?
Is there a way to send issue to acceptance before moving it to sprint form backlog (status in workflow?)? Once again please forgive me asking for such basics, but like i said in title, I'm going slightly mad with all otf this.

Thank You.

Accepted answers

Nic Brough -Adaptavist-

I think you've grasped a lot of it, but need more help filling in the pieces you don't need. Rather than try to do that piecemeal, I find it easier to explain from scratch.

You have a pile of items that need doing. In Scrum, these are Stories. Jira uses "Issues" as the main word for these items, but you can (and usually should) use several different types of issue with names that keep it clear. You could, if you wanted to, create a Scrum project that only has one issue type, that of Story.

Jira was not originally written to be Agile. It is an issue tracker. When you've got issues, people often like to break them down, and so you ended up with sub-tasks. But these are not part of Scrum, and they don't get estimates. You commit to dealing with Stories to your Product owner and a Story is either done or it is not. You don't commit to doing parts of a Story in a sprint (if you do, your story should have been split up)

Jira Software also implements Epics, which are a convenience for grouping together stories (especially when they're too large to fit in a sprint and need to be split). Epics are poorly named if you want to do scaled agile, but that's another story.

Initiatives and Themes are organisational layers that are a bit above Epics - an initiative typically has many Epics in it.

I think Dave covers the rest of the things you were asking about, so I won't bore you with that!

All comments

Dave Theodore [Coyote Creek Consulting]

It would probably be worth reading a little about Agile methodology. It sounds like you are using Jira Software, which is designed to work with Agile teams. Some of the confusion may come from not knowing when you use a "Story," what "Backlog," "Sprint" means, etc.

There is no hierarchy between Issues, Versions and Releases. They are different things. Atlassian calls the type of tickets you can open "Issues." Each Issue type can have a different look & feel. For example, when you open a Bug issue type, you would typically indicate which version you found the bug in. When you open a Task issue, the concept of a version may not make sense, so you might not include that field. Each issue type can also have its own workflow. Maybe a Bug follows a different path to "done" than a Task issue does.

Version and Release are basically the same thing. You would add a version field (say, for example "Affects Version" on a Bug issue type) and then enter a value when you create the issue.

In Jira's Agile Boards, issues are placed in the Backlog initially. As you move them to a Sprint, they no longer show in the Backlog.

Jira is a highly configurable tool. My recommendation would be to keep things simple. As you grow and need more complexity, add complexity at that time. As I am find of telling our clients, "Just because you pay for all that power doesn't mean you have to use it all at once." Think through your people process. Then configure Jira to work with that process.

Jaromir Toke

Thank you very much for Your answer. However, I am a little bit in a different place. I am supposed to adapt Jira to an existing project and in fact several projects, so I try to understand how associate Jira, with them. For a beginner, this is not an easy task. As for Agile, I have basic information on this topic. It rules are quite clear. However, in confrontation with Jira, I'm a bit confused.
I understand how backlog and sprint work. However, it's not clear for me why I need to add a story to the sprint since I have multiple tasks associated with that story. It seems to me it's unnecessary to litter the sprint, or I'm wrong?
Initiative is the most mysterious creation for me. I completely do not understand when and whether to use it. What relation does it have to the version and to the epic. Epic vs version vs initiative, how to understand it?

Nic Brough -Adaptavist-

I think you've grasped a lot of it, but need more help filling in the pieces you don't need. Rather than try to do that piecemeal, I find it easier to explain from scratch.

Initiatives and Themes are organisational layers that are a bit above Epics - an initiative typically has many Epics in it.

I think Dave covers the rest of the things you were asking about, so I won't bore you with that!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

scrum