JIRA is now available as three separate applications, JIRA Software, JIRA Service Desk, and JIRA Core. For more information on administering these applications, refer to the Administering JIRA Applications documentation.

What is a Project

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

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

25 Archived comments

  1. User avatar


    Can Versions be linked to Components?

    17 Mar 2011
    1. User avatar


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

      09 Jun 2011
      1. User avatar


        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)

        18 Oct 2011
  2. User avatar


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

    05 Jul 2011
    1. User avatar

      Giles Gaskell

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

      29 Mar 2012
  3. User avatar


    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 ?

    16 Jul 2011
  4. User avatar


    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? 

    24 Feb 2012
  5. User avatar


    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?

    29 Feb 2012
    1. User avatar

      Giles Gaskell

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

      29 Mar 2012
  6. User avatar


    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?

    21 Mar 2012
  7. User avatar


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

    23 Mar 2012
  8. User avatar


    Do these questions only get answered once a year?

    29 Mar 2012
    1. User avatar

      Giles Gaskell

      29 Mar 2012
  9. User avatar


    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?

    04 May 2012
  10. User avatar

    Brandt Daniels

    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.

    17 Apr 2013
  11. User avatar


    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? 

    17 Jun 2013
  12. User avatar


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

    30 Aug 2013
  13. User avatar

    Jason Terando

    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?

    31 Jan 2014
    1. User avatar

      Tobias Kremer

      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. 


      17 Feb 2014
      1. User avatar

        Jason Terando

        Hi Tobias, thanks for the insight. 

        17 Feb 2014
  14. User avatar

    Danilo Seki [DASA]

    I must say this is the most difficult concept to explain. Mainly because JIRA projects usually are not actual projects in the project management concept. They do not have start and end dates. Usually systems are not projects, they are programs with no planned end dates. On the other hand, their versions usually are projects, part of a larger program. That being said, I usually find it easier to explain JIRA projects if I name them "spaces".

    14 Nov 2014
    1. User avatar

      Warren Thompson

      Hi Danilo Seki [DASA],

      Thanks for the feedback. Projects are rather difficult to explain in a generic sense, as depending on your specific use case they could be so many different things. That's the down side of having such a flexible system, trying to name "things" will never suit every use case unfortunately. I won't even start on issues... (smile)

      Thanks again for the feedback!


      16 Nov 2014
  15. User avatar

    Nereida Lark

    Can you create a custom field of type version that utilizes the versions list set up for fixVersion and AffectedVersion

    06 Jan 2015
  16. User avatar

    Michael Blackstone

    As noted in the documentation above, JIRA has a standard field called "Affects Version(s)" yet none of the reports for versioning seem to use it. Can someone please explain this? I would like to use Affects Versions to have a list of known issues in the release notes and in other ways. Surely this is not an oversight, but it doesn't make sense to me. Anyone?

    Examples of Atlassian documentation. "Affects Version" is nowhere to be found ...

    "The Change Log and Road Map reports are driven by the 'Fix Version' field on each issue." (Link: Managing Versions)

    "The release notes contain all issues within the specified project that are marked with a specific "Fix For" version." (Link: Creating Release Notes)

    15 Jan 2015
  17. User avatar

    Erik Erik

    Don't you think it could help to have a clear distinction between product and project ?

    With the possibility to manage some requirements or issues in a project but being able to attach/allocate them to a product ?

    And sorry but i've never seen "project versions" in software development we deliver product or application versions. Ok these versions can be created during "projects" but they're not project versions.

    20 Jul 2015
Powered by Confluence and Scroll Viewport