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

[Nic Brough -Adaptavist- · Accepted solution]

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:

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

[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".

[Chris Megson]

So in my case do you think it is best not to use Epics?

Instead have a Custom field for the Interface or use a component? And use issue linking to link a HLD and LLD task to all the Technical Services it relates to?

[Nic Brough -Adaptavist-]

Yes, I think in your case you should be using fields to classify the issues with their Interfaces. 

Component is one option, definitely, but 140 of them might be a bit much for it, and it's also multi-select which means an issue can belong to more than one Interface.  If that's not true, I'd move to a select-list, or even cascading-select where you could group them up a bit and possibly make the selection a bit easier for the users.

Issue linking the HLD/LLD issues to tasks might make sense, if there's always two issues for each.  I'm not sure from what I've read that HLD/LLD isn't actually a mandatory radio button on your issues though - so any issue would always be one or the other.  Or possibly two sub-tasks on each new issue (if you've got access to scripting, you could say "when new issue is created, also create a HLD subtask and an LLD one on it)

[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.