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; } } }

What is the best way to break a project down?

Chris114

I am fairly new to JIRA. I need to structure a project that consists of 4 sections. Within each section I would like to split it down into two further sections and then create the issues under either of these categories.

I was thinking of making 4 Epics. Then within each Epic I would have two Stories. But this is where I get stuck. Now when create an issue I would like to associate it with one of the 2 stories that falls under the specific Epic.

What would the best way to go about this be?

Accepted answers

All comments

unknown

You have several options:

Use a Sub-Tasks so your hierarchy will be Epic > Stories > Sub-Tasks

You can just "Clone" issues so that you can re-use them. There's a feature for "Template Issues" (https://jira.atlassian.com/browse/JRA-7731).

Why do you want to associate one story to two Epics? Saying I have EPICS named "User Interface" and "Database", what kind of story will need to exist in both of these EPICS? Maybe you could take a look at creating another EPIC for that?

Fabio Racobaldo _Catworkx_

Hello Chris,

you could use labels/components so that you can aggregate issues within a project. I suggest you the following article http://blogs.atlassian.com/2013/11/organize-jira-issues-subcomponents/ by @Dave Meyer.

Hope this helps,

Fabio

Dennis Poort

I do not see where the question states that he wants a story to exist in both epics?

Chris114

Thank you for the replies! Very Helpful.

Just to be clear on the structure that I require. I would like the project broken down similar to this:

Capture1.PNG

So I have found that there are perhaps 4 different ways of doing this:

4 Epics > 2 Stories > Sub-Tasks
4 Epics > 2 Stories > Issues (Issues liked to Story)
4 Epics> Issues (Assign components: New and Old Functionality) - As Fabio Suggested above.
Have 4 projects instead of the one. With each section being its own project. Then two Epic's: New and Old Functionality > Issues.

Am I right in thinking that these are the only way I can achieve this? And do any of the methods have any particular advantages or disadvantages?

Capture1.PNG

Dennis Poort

Are the sections really different projects? Or just different kind of category changes? Are different developers going to be working on the different sections, or all is maintained by the same developers? Is the splitting up between new and old functionality because you are developing a completely new software VS maintaining the old software? Is the new going to replace the old, or will the old be upgraded by new functions? Not saying that I will have the solution/best approach tip for you, but I can image that a decision to not split it up in new vs old, but just planning different sprints could be the case. Or versioning them could be an option or not. Curious in your answers and those of others here.

Chris114

The sections are within the same project yes. Just a different segment. The developers will be working across the sections. New Vs Old is the Addition of new features and the migration of old features.

Chris Megson

Hi,

I still can figure out what the best way to structure the project is. Basically the main project is the SOA Implementation and within that there are 4 projects: MR, CEP, PS and Legacy.