Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Projects as building blocks and hierarchy

Hello everyone

I've the following issue and I want to be sure which is the best way to implement this using Jira...

I've a software product that consists of several smaller projects in hierarchy. For example PRJ 1, PRJ 2, PRJ 3 etc...


When these PRJ 1,2,3 will be implemented will act as components for bigger projects...

For example the PRJ 4 will consist of PRJ1 + PRJ2 as well as some other tasks...

At the same time PRJ 5 will need to use again PRJ1 as well as PRJ 3 and several other tasks.

Then PRJ4 and PRJ 5 will included in bigger projects eg. PRJ 6 etc...


As a result, I've to implement a project hierarchy as well as I need several projects to participate in different project hierarchies... 

What is the best way to implement all the above?

Thank you in advance.


2 answers

We have some similar structures in our installation. We have a basic set of rules that covers 90% of our needs:

Rule 1: Use the same workflow for everything. 

Rule 2: Use the same board layout (Kanban with Backlog and four columns (todo, in progress, in review, done)) for everything. 

Rule 3: if you have to use a different workflow try to map it to the same columns. 

Rule 4: One project one board. So project leads can modify their swimlanes and quickfilters to fit their needs. 

With this set of rules we can cover most of all projects and our users need to learn Jira only once. 

In rear cases we create collector boards that cover multiple projects. These boards are additional boards. They do not substitute the regular project boards. In day to day business our users go to their project board. For coordination the project leads go to one of the collector boards.

The mastermind of all collector boards is our “my tasks” board that shows all task of the current user regardless of the project with swimlanes by project. Thanks to rule #2 this board just works. [filter: (assignee = currentuser() or reporter = currentuser() or watcher = currentuser()) and (resolution is empty or resolutiondate >= -2d)]. 

The more variation you allow in your projects the more hassle will come along. Try to create a set of rules and stick to it. Protect you rules agains other fancy ideas form new colleges, your boss or anyone else. If you think you have to bend or circumvent your rules, sleep one night and think again. If you still think it is necessary, write documentation that explains what you have done and why.

By the way: this simple set of rules (plus the naming convention plus the standard permission set plus Confluence integration plus plus plus ...) took us about six month. We refined it over and over again but now it’s stable and we can create new projects within minutes without thinking what might be the best solution. There is only one solution. Period. 

Very helpfull guidelines that will save me a lot of time... I really appriciate your sharing experience.

Hi @Constantinos Lempidakis 

Can I confirm:

  • You have one software product
  • This is made up of several projects - projects 1-3
  • Components of projects 1-3 will be used for other future projects - and onwards from there

^ If this is the case, I would decide first what the project structure should be. A project in Jira is a collection of issues - but that does not mean it has to be an actual project. It could be a team, a product, a program of work - or whatever you need it to be.

For example, things to consider:

  • Versions: Do the projects have separate releases, or could issues from all projects be in the same release? This is important as by default, versions are specific to one Jira project.
  • Project Size: How large are these projects? Should you have a project per project, or can you manage multiple deliverables in one Jira project? For example, sub-categorisation could be managed using project components.
  • Teams: How many teams are working on these projects? If one team is working on all products, they might want to release issues in a single version, so one project would be more beneficial. If each project has a unique team, perhaps a project per team would be ideal?
  • Program: If this is one deliverable broken into multiple projects, is this a large program of work? Or a roadmap for a product spanning a long time period? If it is, you could consider an app which would extend Jira's functionality to allow for multi-project releases, a full view of scope and to manage team capacity - such as Advanced Roadmaps for Jira
    • Note: This is an app for Jira Server, but is bundled into Premium for Jira Cloud.

Deciding on project structure will help you decide the best way to break the work into manageable chunks, relate it together to show dependencies and provide the best view of progress.

If you can provide more specifics on project size, how projects will be structured/released and teams, I'd be happy to provide my view on a good approach!



Thank you for your reply.

Answer to your questions:

1. We've many different software products.

2. Yes, its final software product consists of several smaller projects that we are combine them together. These smaller projects may consists of other smaller projects too. By making different combinations we make different final products.

3. Yes, as I stated in No2 smaller projects act like components for future projects and different combinations.

4. Each project even small mid or big has its own versioning.

5. One project may consists of smaller projects. These smaller projects may consists of other smaller projects... etc..

6. There are different teams that works on different projects.

7. It is one delivarable broken is several other smaller projects. Consider these projects as buildings blocks. You use smaller blocks to build larger blocks. And then these large blocks are been used to create even bigger blocks until you reach the final product.


Since we are now ready to start using Jira we want to be sure which is the best practice for our needs...

Thank you in advance. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Apps & Integrations

How we use Jira Service Management for our recruitment process! - Part 2

It is never about setting up a process and being done with it. Rather, the focus should always be on optimizing it for the best outcomes. Thus, we didn’t stop at setting up JSM for our recruitment pr...

180 views 0 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you