How are your Jira projects organized?

[Josh Costella]

Need your feedback! How does your company organize your Jira projects?

• By Team?
• By Product?
• By Value stream/initiative?
• Other?

(The above is not a hierarchy, btw. Just a common list of how I've experienced other companies organizing their Jira projects.)

If other, please let me know in the comments!

Also, please let me know why your specific organization method has benefited you. If you have any kind of accompanying data (doing this saved us % in doing that) that would be great too!

[Sarah Spalding]

Mostly by Product because once the Product launches, the project can be "closed/released". However, we do have some newer teams that manage work by Team as they are more kanban and we are scrum. We are trying to set standards for the dept/company at this time so looking forward to seeing other responses!

[Ken Siskind]

All the companies I have worked for primarily organize their Jira projects by team.  We may have a few strategic projects where we create a specific project for it, but generally we organize by teams.   Mainly because 1 team typically has multiple projects that they work on over the team's lifespan so we can just keep the same Jira project and add more Epics to it.  We don't have Advanced Roadmaps, so if we need to flag multiple Epics that are related to one project we will apply labels to the Epics.   When we started getting a lot of Jira projects, we use the "category" option to help group related teams together.  And also use the Project description field to add some info about the team that owns the Jira project.  

[John Fetzik]

We have all of those you listed. We also have the following categories.

• Library support, for common code used across multiple products 
• Other cross product support, mostly policy/process stuff such as cybersecurity, PCB design, UX design standards, etc.

[John Fetzik]

Based on the discussion I figure it might be useful to expand our case a bit further.

I work for a manufacturing company that produces switches, fuses, and the metal boxes they go in, for the electrical power grid. About one third of what we sell includes embedded systems to monitor and control what's in these metal boxes.

For us that means that the vast majority of work done using Jira is not purely software, but also includes electronic hardware design, procurement of electronic and electrical components, field service teams, and in some cases even the layout of the manufacturing line. The key thing here is that we do not sell software without the accompanying hardware.

One thing to note is that we have been working on being a lean manufacturing organization for over a decade now. So everyone can relate to Kanban boards, because this is used througho0ut our entire manufacturing floor.

About half of our, about 70, Jira projects are based on a particular product or product line. In our case these Jira Projects will last as long as the products does. A number of these products are older than our use of Jira, and the oldest that we still produce, update and maintain is over 30 years old, and thus well older than Jira.

The key thing for these product based projects is that the activity and the people working on them can be very dynamic. When a product is new there is a lot of people and activity. As the product matures activity declines, so folks move between projects and work where they are needed. Almost no one works on just a single product/project.

All of these projects use the same custom issue types and workflow that has been developed over the past decade that matches our specific processes. Most of these use a pseudo-scrum work process. With the software developers using sprints and other job tasks using Kanban.

The remainder of our Jira Projects vary a lot, but 90% of them are pretty much out of the box Kanban. 

We have a few purely software projects. These are based around dedicated teams of people. Unlike the product related work these teams are not very dynamic.

One team supports a remote monitoring service, and the associated custom software, we provide for some of our products. Another team creates small applications and reports related to gathering data on the shop floor. Another team maintains the customized embedded operating systems that a lot of our products run on.  Another builds and maintains test equipment used in the manufacturing process. And so on, and so on.

On the IT side we only have a couple Jira projects. Since getting rid of the old mainframe systems in the Y2K era we don't write custom software. We mostly deploy and configure third party, off the shelf applications. For this kind of work we have used Microsoft Project for decades and continue to do so.

There are a couple IT related Jira projects. These are used for frameworks/middleware that you build an end user application on top of. They involve both extensive configuration and some custom code. So these projects are application based.

[Johnny FromCanada]

So, what’s the problem? 😬

[Tom Horton]

We do it by value stream

[Bill Sheboy]

Hi @Josh Costella 

What problem are you trying to solve in asking this question?

For example, are you gathering data for a vendor/product development, looking for ideas to improve your own team's usage of Jira, researching for an educational project, or something else?

Thanks, and kind regards,
Bill

[Josh Costella]

Thanks for the response Bill! I am asking as a way to gather data to inform/support a reorganization method. I don't want to get too much into the weeds of how things are structured for us today but the ultimate point is I am gathering supporting info to make the case for the proposed improvement in how we do things. I will say this is a change that has to happen because of system limitations we've encountered.

[Matt Fahrner]

Project at the moment, but I wonder if we should be shifting toward value stream.

[Eric Raymond]

This is a very interesting question and I had to stop and think for a moment. I've been using Jira now for a decade at three different companies with different processes and products in each but it all seems to ultimately gravitate toward the "Team" doing the work. Our Jira projects seem mostly to be long lasting (not the original technical definition of a project which has a specified beginning and an end).

It doesn't matter what the project was originally called but all the issues are associated with that given "project" because there is a specialized team with a specific skillset doing the work that becomes related to that project. This is especially true with scrum teams and service management teams. We could be doing it wrong but I've never had a scrum team belong to more than one project. Individuals themselves could be assigned issues in multiple projects, but the scrum team that does the work by and large gets most of their work from an individual project in Jira. Sometimes in the case of shared resources, you'll have crossover with certain people participating in many projects within Jira but the bulk of our teams are self-contained within their own projects.

Unfortunately I don't have any stats on what works best. I know that Atlassian has recently introduced the Teams concepts in Jira Cloud. It will be interesting to see how the two combine to make a better experience. I'm sure there are improvements we could make but this just seems to be the natural approach.

[Ken Siskind]

This lines up with my experience with Jira at 3 difference companies over the last 10 years or so. 

[Karen Rogalski]

There is no wrong or right answer.

For very large organizations with multiple product applications and stable teams that support those applications, using a Jira Project for that application teams makes sense.

For smaller organization with a single application, then using multiple Projects for each Initiative might work better.

So it really depends. Jira can help organize your company and do the whole transformation Agile thing, but in the end; your tools must reflect your company, its organization and its culture.

[Gordon Macdonald]

Good question - I have often struggled with how to structure Jira with multi-disciplinary teams, especially when the teams  include other engineering disciplines, who work at a different cadence,  as well as software teams.

Too many Jira projects can become a burden.

Generally we have a Jira project which is all the issues relate to a product, primarily I think because the issues related to a single product need to be visible together, and are released together. Usually new work starts with a product definition or major feature change ( initiative) to  a product.

However, we use boards rather than Jira projects in organising day to day work ( i.e. to organise our projects). These boards may be across products and teams.  Team members often work on multiple products.

I wonder if versions could be alternatively linked to boards rather than projects.  Not sure how best to do this:   e.g. have only one project for all issues  and  create board filters based on a set of versions or use the component field or a specific custom field.  I avoid the label field for shared filters as it is free text and prone to typos.

Advanced Roadmaps make this less of an issues though. 

Having an extra hierarchy level above Epic  but scope driven, rather than time driven,  is very helpful, both in planning and in reducing the number of Jira projects needed.

Often the higher level  will have issues related to more than one product.

[David Wuth]

Advanced Roadmaps has been a HUGE help in having a higher level visibility to multiple projects, and also a way to organize work by team instead of by project.

[David Wuth]

Great thread and discussions! I work for a small software company. We have four major product lines and several sub-products that align sometimes with a single major product, sometimes with multiple major products. Our deciding factor on how to organize Jira projects was our release strategy for each. If a sub-product is ALWAYS released with a single major product, that work is kept in the same project as the major product. But, we found that most of our sub-products are released (and versioned) independently and so we found it easier to have separate Jira projects for each of those. Thus, if a sub-product is required by multiple major products, we can say that version 1.9 of sub-product A is a requirement to deploy version 3.6 of major product X and version 4.1 of major product Y. We never close a Jira project.

We also have some Jira projects for non-release work. For example: We have a project for DevOps and a separate project for IT Ops. There can be some overlap in those two groups and even with product releases. So, we have had to be creative in how cross-project work is displayed on sprint boards, especially since those projects are not necessarily on the same sprint cadence.

[Jason Hayman]

I work at a small SaaS company - from 150 to 200 employees total. We have 5 cross functional, self-sufficient engineering teams (devs, QA, PM/PO, & UX/UI designer) each responsible for their own area of the software, including new work, maintenance, refactoring, architecture, etc.

We set up one Jira project for each team. Each team (Jira project) can have only 1 board. Any more than 1 and work gets too easily lost. We use epics to represent a project or large chunk of work that team will be completing.

We have occasionally spun up a short-term team for special projects, but still team based.

A simple approach that supports us well.

[Johnny FromCanada]

Typically one "project" per Team, since in the Lean-Agile way, we bring work to people, not people to work.

But also have done unified, where all Teams are in same "project", and filtered via a custom "Dev Team" field (since Jira is fundamentally a filter-based system).

[Vilius Zigmantas]

~500 people organization

Projects per team, product, or a service. Plus a few higher-level projects to track organization-wide projects/initiatives and objectives. All cross-referenced and cross-linked through Parent Link (see Advanced Roadmaps), which allows to set objectives > split effort into projects/initiatives > distribute the workload to teams in Epics. Team projects use unified structure with Epic/Task/Sub-task issue types and workflows. Each team create Epic per project and self-manage the related effort in there. This way all layering, estimates, progress, etc rolls up in Advanced Roadmaps for management. 

Service projects are for teams that besides main effort also provide enterprise service to other teams (e.g. infrastructure can do work on projects/initiatives, but also provide infra management as service). This means that some teams will have two projects: project work and service.

Otherwise this is a very wide question with a variety of solutions available. Where a starting point would be to understand how organization is looking to track their work from the lowest to the highest level, what links to what and how comfortable teams/leads with available approaches. It helps to think in terms of streamlining the value delivery (i.e. path of least resistance from idea to customer value).

Hope this makes sense. If not, let me know.

[Lorenzo Phillips]

Any of the options you mentioned will work just fine. In my experience, the key is consistency across the enterprise. I've had many clients that had a mixture of the options and it caused confusion when resources transitioned to other teams because projects were just "too different" or it made the task of roll-up reporting very challenging (if the client could do it at all).

Management tends not to be involved in the details of how Jira is setup, but somehow always seem to ask for certain reporting that shows the gaps after the fact. For example, I've had clients setup product-based, but management started asking for reports that would be better suited for team-based. Or in an environment that has both options, then the reports were incomplete because you could only report on a subset of the projects and not the whole.

Now, if things were setup correctly, a mixture would not matter as you'd have certain fields properly capturing the necessary data points and thus, you could still obtain the required data from all the projects and generate the necessary reports and rollup reporting.

In my experience, when my team and I are brought in to setup or address the current environment's reporting gaps, the key to our success has been to ask questions like:

• What reporting is required for the business?
  • Do the reports need to be cross-project/rollup oriented?
  • Does the business track billable hours? If so, to what level?
  • Is there a portfolio-level tool in the environment (ex. Jira Align)?
  • Are there any regulatory/compliance guidelines that need to be followed?
  • What data points are important to management?
• How do the teams prefer to work?
  • Scrum, Kanban or both?
  • How do teams work (ex. Dev, IT, QA, PM, etc.)?
  • How are releases being tracked (ex. Product-level, Feature-level, etc.)?
  • What data points are important to the teams?

This is a subset of what we look for (and the post is long enough already-Lol), but once we have all of the necessary information, we then start mapping things in a manner that clearly shows how things should be setup. Some times, it can just be at the project-level. Other times, we need to drill down to the field/screen-level. Project-level is used when we can setup one option for the whole business (ex team, product, feature, etc.). Field/Screen-level is more for clients that need a mixture of the options and we need to allow each team to work the way they want, while ensuring we generate the reports the business deems critical to its needs.

In the end, our clients have been happy because teams could work in a manner that was best for them and management could obtain the key metrics/reporting for their decision making.

Finally, you'll also want to have some standards implemented. You cannot effectively generate reports in a mixed environment where everyone is allowed to have their own statuses, priorities, resolutions, etc. It can be done, but it is much easier to say "give me all of the issues that are In Progress, across all projects" than it is to say "give me all of the issues that are In Progress, Work In Progress, Open, Started, In Dev, etc., across all projects". Having standards will make it much easier to have and maintain an environment that uses a mixture of the options you've listed.

Sorry, that was a long answer but hopefully it helps you (or someone else) when considering which option(s) work best for your organization. :)

[Gordon Macdonald]

All our Jira Projects that are product based and share team members also   share the same Work Flows, Issue Types, Custom fields  etc. Devops, HR and non product related Jira projects have their own separate configurations. Essentially Jira projects are containers for issues that share versions. Boards are used for team planning and tracking. 

[Christophe Noualhat]

Jira products : By product name

Jira projects : By client / project

[Kristin Lyons]

I work in a handful of different Jira environments and most of the time I see projects organized by team, however I occasionally see projects organized by product.  I always try to push for organizing by team but there are some companies that don't have "teams" per-say.

[Anne Saunders]

I think business model makes a big difference. I used to work at a huge org, where all of our effort was focused internally - we were our only client, and we organized by team.

Now I work in a boutique dev shop, where 90+% of our work is for external clients, and we organize everything by client and product before team.

[Anne Saunders]

We have one Jira project per product, but our cross functional teams also have their own projects (QA, DevOps, Creative, etc.) 

We use labels on certain issues in the product based projects to display (eg) DevOps tasks to the DevOps team in their board without pulling it out of our project boards.

[Deleted user]

We have a Jira project per team. We have initiatives and milestones (in their own Jira project) above epics to capture cross-team, cross-product work.

Our teams are a mix of product, cross-functional, and service teams. Service teams use the Open>In Progress>Closed workflow, and product/other teams use Open>In Development>In Testing>In Review>Closed. 

[Rilwan Ahmed]

@Josh Costella We do it based on teams for our service desk like IT, Managed Services client projects (MSO), Support Client etc

For jira software we create based on roles like QA, Product Development, Internal Projects

[Alex Gay]

Our organization is splitted in domains, each domain contain Tribes and each tribe has multiple squads (scrum teams).  

In Jira we have Projects per Domain, that contain the Theme (strategic teams that can take more than 3 years).  The child issue of a team is an initiative (can take max 1 year) to meet the goals of the parent 'Theme' .

Next to the Domain projects, we have the Tribe projects.  Where the Epics, story's tasks and bugs are stored.  An Epic (can take max 1 Quarter) is the child issue of an initiative.  The Epics are the pieces of work to be done to deliver the initiatives.

In each Tribe project, multiple squads (scrum teams) are working on their scrum board, related to the tribe project.   We differentiate the work by a custom field 'owner'.  So a scrum board filter is like project=tribeproject and owner=myscrumteam

The boards of those 'squads' contains the pieces of work to be delivered during 1 sprint.

If want to know 'why' this need to be done, they can go from story to epic, from epic to initiative and from initiative to theme.

The issue that we have today is that the custom field (Elements connect) to indicate the 'owner' is not always supported by 3th party plugins, so this makes integrations difficult.  And this could be one of the reasons to have a Jira project for each 'squad'

About the workflows and screens, 

There is 1 workflow per issue type. (unless it can be shared)

There is 1 screen per issue type (unless it can be shared).

This way, we work the same in the entire company.

We know it isn't 'Agile' but before each team could do whatever they wanted, create new statuses, new workflows, new custom fields.  This became unmanageable and there was no way to have consistent reporting.

The benefit of having 1 way of working, is that for reporting, we know on what status to report, (they mean the same for all teams) and we know on what fields to report, because the are the same over all the projects.

Also if a member will switch team, they will be familiar with the way of working, as it is the same for all teams.

As an admin, we need to maintain less then 10 workflows and if we change something on for example the 'story' workflow, it is applicable for all teams.  You don't need to execute the change on multiple workflows.

Same for the screens, if an extra field is needed, it only has to be added to 1 screen to make it available for all users on that issue type.

For this setup, we use advanced roadmaps and elements connect.

[Julian O_Loughlin]

Interesting topic - I went searching for the same questions and stumbled across this as I'm new Jira.

I work for a product design company that's using Jira only for R&D. My latest task is to pull in all company facets from industrial design, electronics, sales, marketing, logistics and finance into a single project that's in development. I was hoping to assign epics and tasks based on these teams. Is this possible?

It just feels like I'm creating a rabbit warren in Jira or the Jira project is becoming more of a project design framework than Jira tasks. By the sounds of the above, some companies have Jira projects assigned to each company attribute or facet. How do you tie it all together?

I'd welcome some advice in organising the multi attributes for a single project/product in Jira - don't mean to highjack the thread @Josh Costella