

Skip to end of metadata
Go to start of metadata

A JIRA project is a collection of issues, and is defined according to your organisation's requirements. For example, a JIRA project could be:

  • a software development project
  • a marketing campaign
  • a helpdesk system
  • a leave request management system
  • a website enhancement request system

Every issue belongs to a project. Each project has a name (e.g. Website Issues) and a key (e.g. WEB). The project key becomes the first part of that project's issue keys, e.g. WEB-101, WEB-102, etc:

What is a component?

A project component is a logical grouping of issues within a project. Each project may consist of various components (or none), depending on your organisation's needs.

For example, a software development project could consist of components called 'Documentation', 'Backend', 'Email Subsystem', 'GUI'. A website enhancement request system might consist of components called 'Products', 'Contact Us', etc:

An issue can belong to zero, one or multiple components within a project.

What is a version?

For some types of projects, particularly software development, it is useful to be able to associate an issue with a particular project version (e.g. 1.0 beta, 1.0, 1.2, 2.0).

Issues have two fields that relate to versions:

  • Affects Version(s) — this is the version(s) in which the issue is manifesting. For instance, a software bug might affect versions 1.1 and 1.2.
  • Fix Version(s) — this is the version(s) in which the issue was (or will be) fixed. For instance, the bug affecting versions 1.1 and 1.2 might be fixed in version 2.0. Note that issues which do not have a Fix Version are classified as Unscheduled.

Versions can be in one of three states: Released, Unreleased or Archived. Versions can also have a Release Date, and will automatically be highlighted as 'overdue' if the version is Unreleased when this date passes.

Additional Resources


  1. Anonymous

    Can Versions be linked to Components?

    1. Anonymous

      No, there is an issue for this created seven years ago, see: https://jira.atlassian.com/browse/JRA-3501

      1. Anonymous

        Yes... too bad Atlassian is completely ignoring this feature request even if it is so old.

        I love Jira but there is actually no good way of fixing it (sad)

  2. Anonymous

    Can a Project be hidden in the Project drop down of Create Issue screen ?

    1. One way of achieving this is to restrict the access of relevant users to these 'hidden' projects by removing their Browse Projects  project permission (and Create Issues project permission) from Permission Scheme that those projects use/(are associated with).

      You could implement this via groups by doing the following:

      1. Add all users whom you want to access your 'hidden' projects on your JIRA site into one group (e.g. called 'restricted-proj').
        (info) In other words, ensure that the users whom you do not want to access your 'hidden' projects are not a member of the 'restricted-proj' group.
      2. Add the 'restricted-proj' group to the Browse Projects project permissions for all Permission Schemes used by your 'hidden' projects.
        (info)  Please Note:
        • You may likely need to remove other project roles/groups/users from the Browse Projects project permission for these Permission Schemes.
        • You may also likely need to do the same with the Create Issues project permissions (above as you did for the Browse Projects project permission).

      Hence, any users who are not members of the 'restricted-proj' group will no longer see these 'hidden' projects (nor will they be able to create issues in them).

  3. Anonymous

    to find all the issues that affect a certain version i need to create a specific filter or search

    is there a way to have the issues that affect a specific version appear directly on the overview of a version ?

  4. Anonymous

    We have five software apps(projects) that have shared code. If an issue is found it has to be associated with all five systems and needs to be tested and resolved for all. Each system has a different release schedule so an issue can be resolved in one system and open for the rest. Can the be accomplished with JIRA? 

  5. Anonymous

    Is there a level above Project?  We have many Products and each Product has many simultaneous Projects going on.  We would need to link the individual Projects back to a single Product.  Is there a way to do that?

    1. You can group projects by Project Categories. Refer to Defining a Project for more information.

  6. Anonymous

    Hi, we have a similar problem like the author above.

    We want to use JIRA for product development, each product shall have a backlog for future improvements (backlog items). At a certain time, we want to make a project of the collected improvements. To keep track about the improvements of a product, we need a level above project (like product). Is there a way to do this?

  7. Anonymous

    We want to use JIRA to manage requirements. Where can I look to see how to customize requirement parts and dependency trees? 

  8. Anonymous

    Do these questions only get answered once a year?

  9. Anonymous

    If fix version is synonomous with a release to a customer, then what version or grouping of issues whoul be used to identify the issues fixed and released to the test team for a preliminary test build?  Presumably, testers or the user community report on Affects version.  The question I guess I have is what is best practice in JIRA to communicate what is new and fixed in the current or next test build version what will be included in the release to the users?

  10. The "(or will be) fixed" is where the Atlassian definition of Fix Version differs from ours. We are using the custom field Scheduled Version for the "will be fixed in" and Fix Version for the "was fixed in". Unfortunately this makes a lot of the built-in plugins useless to us.

  11. Anonymous

    I just want to now that "is the Project name specific to the Product release"? For example we have a Product name "XYZ" and have many releases of the product like 1.0,1.1,2.0,2.1,2.2 etc. So do we create a Project in the JIRA for a specific release like "XYZ x.x" or it would be "XZY" for all the releases? 

  12. Anonymous

    I can tell the JIRA is much more focused in products and issues workflow than into the company`s customers workflow, when talking about, for example, a implantation process after a sales process is made (e.g.: Start -> Planning -> Installing infrastructure -> Configuring server -> Training/application -> Finish)

    Is there any way i could use JIRA`s project management tool in order to control all my software implantation projects? (this way, all my projects would be, actually, my customers).

  13. Hi, we've rolled out JIRA in a limited fashion and it's gone pretty well.  I'm considering rolling it out to our larger development group.  We build and maintain a number of heterogenous applications in house (around 30), and my questions are with regard to the organization of projects in Jira.

    Most of our applications are long-lived and we release many versions of them.  Some release versions are small (bug fixes and the like) and other versions are larger, normally what I would consider "projects".  For anybody with a similar development shop, how do you organize Jira?  Do you set up a Project for each major release, and group them by project categories; or do you have one Project per application and use version numbers to organize sprints?  Are there any white papers available for best practices for using JIRA in such an environment?

    1. Hi Jason,

      I would set up only one one JIRA project for each of your products. Creating one JIRA project per major release would only cause you problems:

      • You can not move tickets to the next release (well you can but moving tickets to an other JIRA project causes having them a new issue key and number. So it would be rather confusing)
      • You get the problem when moddeling a Bug or change connected to different versions (e.g. the same problem exists in 1.0 but still exists in your current development on 2.0. Having a project for each major version would force you to create two tickets for the same issue.

      Be aware that affected version and fix version allow you to select multiple versions. So you can create on miner version per spring and collect all these miner versions into a mayor version for your release. Somthing like version 2.0 consists of all the changes made in sprint 1 to 5. JIRA Agile used to support enforcing these kind of version hirachy. 


      1. Hi Tobias, thanks for the insight.