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 Project Structure

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.

I also need to categorise a Task as either Legacy or New.

I am not sure if I should create one project or 4 projects in JIRA.

Want the best way to report across all projects.

So far I have come up with the 3 options below. What do you think is best? Or is there another better option?

Option 1

image2016-1-5 15:37:14.png

Option 2

image2016-1-5 15:37:52.png

Option 3

image2016-1-5 15:38:19.png

Accepted answers

Nic Brough -Adaptavist-

I'd rule out 1 and 2 because Epics are supposed to be large stories about change that eventually get closed off. They have a process, they're not so much for categorising issues, they're about grouping them into chunks of work.

I think you've got two decisions to make:

The harder one is "one project or four". Both are perfectly good approaches and you need to decide based on how your teams are going to work. Are they closely entwined, and do people do a good mix of work on two or more of those four streams? If the four streams are totally separate, then four projects is a good way to do it. If they're highly entangled, use one project. If you're not sure, then have a look at how teams work - you might find it best to have four projects, but then use JIRA Software (Agile) boards that go across all four of them for your teams.

Also, take a look at the versions and components - are they cross all the streams? If so, that pushes you to one project. If they're independent, then four projects is probably easier.

The easier decision is about how to categorise your data. If you have one project, you're probably going to want to have a custom field for MR/CEP/LEGACY/PS. Or possibly use components.

Component fields are multi-select, so a user could select legacy and new. If that's ok, use components for it. You could swap that, and use a custom field for MR/CEP/Legacy/PS and components as Legacy/New.

Or use a custom field for both if they need to be single-select and you've only got one project.

Or you could simplify further if it's a single project - have 8 components, 4 legacy and 4 new, with the four streams tagged into it.

There's a lot you could do, but it should really be looked at in the context in which you want to work, and I can't really tell you that. But I can say:

Look at how closely teams should be working
Think about the sharing of versions and components (As they belong to projects)
Design your field usage by looking at the reporting you want to do!

All comments

Nic Brough -Adaptavist-

I think you've got two decisions to make:

Also, take a look at the versions and components - are they cross all the streams? If so, that pushes you to one project. If they're independent, then four projects is probably easier.

The easier decision is about how to categorise your data. If you have one project, you're probably going to want to have a custom field for MR/CEP/LEGACY/PS. Or possibly use components.

Or use a custom field for both if they need to be single-select and you've only got one project.

Or you could simplify further if it's a single project - have 8 components, 4 legacy and 4 new, with the four streams tagged into it.

There's a lot you could do, but it should really be looked at in the context in which you want to work, and I can't really tell you that. But I can say:

Look at how closely teams should be working
Think about the sharing of versions and components (As they belong to projects)
Design your field usage by looking at the reporting you want to do!

Chander Inguva

Hey Chris,

Did you look at JIRA Portfolio ? https://marketplace.atlassian.com/plugins/com.radiantminds.roadmaps-jira/server/overview

This might be a better solution to work against multiple projects except for the Annual cost of plugin.

Chris Megson

This is brilliant! Thanks Nic, just what I was looking for! I think I will go for one project as they are quite interrelated. And I will make custom fields for the streams and Legacy and New because they need to be single select. I think 4 projects may be too much duplication because the workflows and components are the same. Thanks so much! Chris

Chris Megson

Hi Nic. I need some further advice. I now need to also group Technical Services by Interfaces. We have 142 Interfaces and each Interface has one HLD and LLD. So one Interface may have many Technical Services.

I could have one Epic per Interface and within the Epic have one HLD, LLD and however many Technical Service tasks there are. In this case would 142 epics be too many?

Chris Megson

Hi, My requirements for the project have changed since I posted my initial question. I will remain with having one project in JIRA. I just need some further advise regarding structuring. The project will still be made up of four different areas: MR, PS, CEP and Legacy. The project is beginning with Legacy tasks and these are due to be completed by 2017. The backlog of Legacy tasks will be added first.

This is the project component structure: Interface > One HLD and One LLD > Technical Services > Individual Tasks.

So I now need to also group Technical Services by Interfaces. We have 142 (Legacy) Interfaces and each Interface has one HLD and LLD and one Interface may have many Technical Services.

I could have one Epic per Interface and within the Epic have one HLD, LLD and however many Technical Service tasks there are. In this case would 142 epics be too many?

Or I could use Issue linking to link one HLD task to many Technical Services, but then how would I group Technical Services by Interface?

Thanks in advance!

Nic Brough -Adaptavist-

That's a misuse of Epics again. Epics are collections of pieces of work to do, not ways to classify issues by their content.

I don't quite understand why you're trying to map the heirarchy of your classifications into issues. Issues are "things we need to do". You probably just want fields to say "interfaces", "area" and "hld".

Chris Megson

Im trying to do it so the backlog can be managed easier. I thought I could put in Epics as they are a collective piece of work that needs to be done in order to complete the interface.

Could I use the SCRUM plan mode without epics?

Nic Brough -Adaptavist-

Absolutely - scrum doesn't require Epics, they're just very useful when you're in planning and say "hang on, that's a massive chunk of work which we need to break down into bits", or "oh, there's an overarching big bucket of things to do get there, lets tie our issues together".

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-core