Best Practices: Strategies for Defining your JIRA Projects

[#1]

One of the most common questions I get speaking with new JIRA users (and even some experienced ones) is how to best organize their JIRA projects. While there's no one way to organize JIRA projects, there are some parameters to consider. In this article I'll do three things:

1. Define what JIRA projects are
2. Detail some common ways of organizing projects in JIRA
3. Provide some factors to consider as you plan your projects

The goal is that by article's end, you'll be making more informed decisions on plotting out your instance!

What is a JIRA project?

At a base level, a JIRA project is a grouping of work items or, in JIRA terms, "issues" that are held in common. If JIRA issues are a variety of different colored, shaped, and purposed LEGO pieces, projects is a box that hold them. Each issue contained within it will share a common key. So, for project "Lego Castle," issues will be itemized as, LC-1, LC-2, LC-3, and so on. 

Simple enough, right? Beyond that, JIRA projects will stand alone in a few ways.

1. JIRA project issues will share common potential configurations. Whether they are workflows, fields, screens, etc., available configurations will be defined on a project-by-project basis based off of issue type.
2. Projects will have their own permissions system, i.e. which groups of users can access the project, which issues they can see, etc.
3. Projects will have their own versioning or release index, i.e. LEGO Castle v. 1, v. 2, etc., as well as components.

One last thing to note, projects in JIRA aren't by nature terminal. By default, you should consider projects as ongoing efforts. To take our LEGO analogy further, you aren't just building a stock, prepackaged castle; you're adding additional drawbridges, turrets, etc. as you go along in an ever-evolving endeavor.

That said, you can certainly close out and archive projects pertaining to ad-hoc efforts.

So, how do other JIRA users organize their projects?

There are a few strategies that are commonly taken with respect to organizing projects. Again, there's no right or wrong way - it's simply a matter of appropriate fit.

1. Releasable product - If you're a software development team looking to make heavy use of the JIRA release and versioning system, you'll want to give strong consideration to organizing your projects by releasable product or groups of work that share a common release cycle.
2. Team - Team based projects are another common organizational model. This allows your work to mirror your social organization and is convenient in less cross-functional setups, as it allows for more straight forward project permission management.
3. Business Unit - Closely related to organizing around teams, you might consider also organizing around larger business units - marketing, product, IX, IT, and so on. Types of work will likely fall into similar patterns, making setting up workflows - and issue types particularly - more convenient.

Within these categories, you can get as granular or as broad as you want or you can even mix and match - just try to mirror your organizational habits and proclivities in your project setup.

A note of caution on Team and Business Unit setups: If your business is prone to consistent reorganization, this could create quite a bit of headache for you as a JIRA administrator. Merging projects and project settings can be cumbersome, so consider your organization's stability before proceeding.

Other Considerations

So what else might you want to factor into your decision making?

1. Components - Be aware that you can still sub-categorize issues within a given project using components. Perhaps you have a small mobile team that does a lot of work both on iOS and Android. Rather than split them up into unique projects, think about using components, or even a custom field, to further parse out your work.
2. Independence - Let's go back to the mobile team. While in some cases iOS and Android developers might want to work out of the same project due to high correspondence in release cycles, proposed feature, etc., if the two efforts are entirely forked, the work could be disparate enough to justify separate projects. Requirements over time could develop to be entirely independent and justify separate projects rather than a shared one.
3. Boards - A lot of users assume that boards need to correspond to projects 1:1. This isn't the case! Since boards are filter-based, they can map to multiple projects. Don't let a boards restrict how you schematize your projects.

So there you have it! While this isn't a comprehensive rundown of what considerations you might make in terms of project organization, it should help you get started and stir up some ideas.

If you've organized projects in alternative ways, feel free to comment below!

Footnote: This article is a bit of a starters guide to JIRA projects and how to get going quickly. If you're interested in diving further into the nitty-gritty of JIRA Software, nothing beats a deep read of our "Configuring Projects" documentation.

[Nicolas Seronvalle]

Nice overview of how to work with projects in Jira, thanks!

Another way to organize projects is to match to "business projects". For example you have a project with a specific customer: several teams will work together, maybe several applications impacted (so you could need to have projects organized for releasable products in parallel and linked issues between "bussines projects" and "releasable projects"),...

A common concern is also about the size of the project versus the number of projects. Is it better to have one big project (maybe with components to organize it) or several small projects?

I guess here it really depends from one individual to another.  But some stuffs one could consider to contextualize as much as possible the day-to-day work: do you need many different issue types between business projects? Are there many differencies in the screens/fields/workflows steps you need from one "business project" to another?

I tend to think that small projects are more manageable, above all if they can share most of their configuration. Given cross-project reporting is possible it does not represent a barrier.

[Denis Boisvert]

I keep explaining the same thing to my users.

It's also possible to organize projects by the type of work that need to be done. If everyone is managing some issue type the same way, you could have a project just for these types of task.

[leroykahn]

If your business is prone to restructures try using something stable like Value Chains or Industry Service Models. These should only change if there is a fundamental change to the business, instead of when managers just try to carve out bigger teams ... 

[Nicolas Seronvalle]

Hi Leroy,

So you would make one Jira project for one activity of your value chain?

Denis, your method sounds interesting, do you have an example?

[leroykahn]

Hi Nic
We have "BAU" ones at Value Chain level, so one for Marketing, Sales, Operations, Customer Service, etc and a few for supporting Functions like IT, HR, Finance, Risk and then we have a JIRA Project per Business Project. But they are all using the same Schemes which we have kept simple (only 2 workflows). We then use JIRA Portfolio Shared Teams (vs another Custom Field) to identify Accountable Teams.   

But do agree with Denis, in an ideal world your whole Enterprise could you use one project! We should be guiding business to a simple solution not acceding to trying to replicate every teams complicated, highly managed business process. 

[Nicolas Seronvalle]

Yes sure keeping the things simple and avoiding to replicate is key.

On the other hand, one generally like to have a synthteic view of projects so all business project under one Jira project doesn't necessarily answer to the needs in the best way. Even if the workflows, issues, ... are the same and even if you propose lots of filters.

Finally it's all about finding the right balance, a tough but rewarding excersise :-)

[AdamLeBlanc]

Has anyone tried the new Jira interface yet?.. I think its only available to some cloud users.  I wasn't too worried prior about using multiple projects within a board since the main menu has a "boards" pull down to help decouple boards and projects. The new interface however.. couples the two more. Now.. to get to a board, you need to goto it's project first and then select the board.  I'm afraid it will make it less intuitive to use a single board to track & manage multiple projects.

Link to information about new interface

https://confluence.atlassian.com/jirasoftwarecloud/introducing-your-new-jira-experience-937886012.html

[Matthew Wong]

Hey Adam,

That's correct - a board will need to be housed in a project. This doesn't limit the board from consuming issues outside of the project it's housed in.

If you need to delete a board to avoid clutter and confusion, you can still do that by navigating to - /secure/ManageRapidViews.jspa. This will prevent multiple boards accounting for the same collection of issues.

[Damian Tremlett]

OK - Just getting my head around JIRA - so it seems pretty clear that a 'project' comes with a bunch of settings which all issues within the project will share  - and Boards are independent (filtered) views of issues from across projects. That seems clear so far and makes for a very straightforward flexible system. 

But then when in project view - it says "boards in this project".  that's not immediately making sense to me - can you explain how a board relates to a project so that it's 'housed in it'. I don't get this relationship, or it's purpose, and would be grateful if you can help me understand it better. 

We have teams that deal with multiple projects, and projects that cut across multiple teams, we also have BAU work that needs to be organised within each team. How do you suggest we set this up in JIRA?

If we have common 'component names' between projects can I filter all issues tagged with 'component x' from across projects into one board ?

[Nic Brough -Adaptavist-]

The "boards in project" is a recent thing.  Previously, boards were completely separate from projects, but there was a clear problem in that a lot of people who did not understand the basic relationship, and believed that they did.

So Atlassian changed the UI to make it easier to find the boards that might be related. 

I think they've made a mistake in the wording, as boards still do not belong to projects, I'd have preferred wording that suggests the relationship, rather than suggesting that boards belong to projects.  I don't really know how to shorten "board may be showing issues from this project"

So, when I say "basic relationship", I mean

• Boards still do not belong to projects
• A board can include issues from projects, so that's when a board should be shown as having a relationship

[Damian Tremlett]

Thanks Nic - that helps to clarify.

We' plan to set up one 'JIRA project' per team allowing each team to set their 'components' and team managers to set workflows. We'll use boards to represent our 'projects' which cross cut the teams.

Based on what I know, this makes sense, but please shout if you see any pitfalls in this plan.

Once again, many thanks for the help.

[Matthew Wong]

Hey Damian,

Based off of your description, I don't see any reason why your proposed setup should not work. Your projects will organize issues by team and then your boards will be predicated upon components and will cut across projects. No problem there.

The only thing that I'd caution is that agile metrics, whether it is velocity, burndown, et al., have a direct 1:1 relationship with particular boards and not projects. Burndown, for instance, is calculated based on how quickly issues are being resolved on your board.

In short, in your scenario, your agile metrics will be predicated on your cross-functional boards and not on your actual "team," i.e. the framework that you've chosen to organize your Jira projects around. Just something to consider, especially if you're going to be leveraging the out-of-box reports.

[Nic Brough -Adaptavist-]

Pitfalls - totally the opposite, it's what I would do with your setup! 

[Damian Tremlett]

Matthew -

I'm assuming that we can have one board per cross-cutting project as you described and also another board for the team leads to use to output velocity/burn down for their team only (which will include their BAU component tasks) 

- Good to know the velocity and burndown are based on boards - I hadn't picked that up before.
-  this way means that most of the issues will appear on 2 boards.  One for team management, and one for project management.  - Let me know if I've stopped making sense.

// -  I'm thinking of a 'board' as being similar to a music 'play list' -  issues are the music tracks - projects are 'albums' -  so an issue can appear on any number of boards, but originates from one project. //

Thanks Matthew and Nic - This is all good thinking, and the assumptions I'm making need to be challenged.  We've also looked v briefly at Portfolio for Jira  - in the hope that we'll be able to integrate this for our Change and PPM team. and capture some critical high level MI reports.

I'm at the very beginning of a long (and probably very bumpy) journey, so setting up the best foundation is going to be key. -

  - am really appreciating this Jira forum positive attitude. - Thank you.

[Matthew Wong]

Hey Damian,

Your analogy is on point! Your proposed workaround works, as well. I'd just make sure to be consistent with which board you do your sprint planning and execution.

[Marc Dvorschak]

Very useful articel. I could use it to explain JIRA and its ideas to my management. Especially  the difference between a JIRA project and the projects the management was used to from classical project management. 

[Rena Mack]

The use of the word 'project' when defining JIRA is interesting, since a project, in PMP land, is a temporary endeavor having a beginning and an end.    It is a Product that has longevity and JIRA Projects, the way I use them, have longevity.  There is a significant difference between 'project' and 'product' especially with management of lifecyles.  Sprints are more like projects where "Projects" in JIRA are more like Products.  Just the opposite of what I read.  No big deal, just thought I would add my input.

And...to continue the thought....JIRA can be used by business (versus IT language) to track work.  This work is not a product nor a project.  For business, I am calling 'JIRA Projects' as applications, because the word project is not applicable.  Not sure I like application either.

I look at JIRA project as a warehouse.  Some warehouses have single rooms, some are multi-faceted, some are simple, some are complex.  It is a very power tool. 

[Mark Foster]

Rena - for your definition of project I believe the Jira equivalent is an Epic?

[Nic Brough -Adaptavist-]

Rena - are you sure a "project" lasts 1-2 weeks and only delivers some of what you've got on the to-do list?  That's what a "Sprint" does.  A sprint is very clearly a time-box within a project, or set of projects.  It's definitely nothing like a "project" in the PMP world.

I think you've got a very narrow definition of project which does not fit the real world of Jira usage.  Jira is used to do all sorts of things, and the "issue containers" (projects) vary widely, they're sometimes aligned with teams, sometimes products, sometimes events, people, etc etc etc.

I'd agree it's not the ideal choice of word for what a project does in Jira, but I'm not sure I could come up with a better one - it's a balance between a word that probably only makes sense to Jira and something readily explainable to people.

[erick.mirandamarquez@telefonica.com]

Maybe something interesting is to plan a project thinking in workshop philosophy; agile projects ("Software") versus traditional process ("Business"), and our window to the world with the "service desk", and the issues types are our "wildcard" to planning the strategy to work, track and support our users and customers.

[Erdogan Yildiz]

Dear all!

Lets assume we are living in an ideal world and i would like to setup one Jira project for all developing issues for multiple products and BAU tasks too.

But the reality is completely different. There are teams which are working agile and other teams not agile. Our aim is to setup corporate workflows and one project.

Other business projects or departments will be setup in different projects with its own workflows.

There are several crossfunctional teams working on that issues.

Which restrictions, pitfalls or problems could arise regarding components, releases, boards in that one project for all developing tasks even if the product are separately releasable?

What would you prefer to setup on this constellation.

I appreciate your help and im looking forward to get an answer.

[Matthew Wong]

Hi Erdogan,

For what reason would you house all your work in a single Jira project? I don't think this is optimal in any way and see no advantage, particularly since there are disparate teams, processes, practices, and release schedules. I strongly encourage you to break out your work and use dashboards and reports to do your cross-project, in application reporting.

[Erdogan Yildiz]

Hi Matthew!

Thank you for your quick answer.  

[Erdogan Yildiz]

Hi Matthew!

What are in your opinion the disadvantages of using one project for multiple products?

The releases could be separated by names (i.e. Naming convention).

The components could be also separated by their names.

Are they any pitfalls regarding permissions or in combination with confluence?

Do you think the mass of data in one project could be a problem for losing the overview?

We are evaluating the best solution for our business needs and therefore we are weighing up pros and cons.

Thank you.

[Tom Synnott]

HI Matt,

How do I tackle 'Company' names in JIRA e.g. I have a customer 'Company 123' they have projects, 'Top Secret iOS App', 'Company Website'... how would you handle that?

Thanks!