When do we need to create a new project in Jira?

[Edward Snowden]

Hi,

I am trying to understand the circumstances which will need a new project creation in Jira (for example, Use of different issue types). I would be thankful if someone can point me more reasons which will need a new project.

Thanks in advance!

[kevin martin]

Consider what needs to be distinct across or between a set of projects.

Workflows need to serve the teams using the project. It should model how they work. Teams doing very different types of work, in different flows, need different projects. You only have one workflow per project.

Products with different release and planning cadence need distinct versions, aka releases aka fixversions. You could have alternative release patterns in one project. However, tgat is troublesome and will not work well if you integrate with roadmap products.

Components are unique to the project. Do you need unique components to serve the product needs or team needs? 

Issuetypes and their screen schemes tend to vary by product and team needs. You could overload screens with many fields or create many issuetypes with unique screens. Its best to create distinct projects if the information/fields need to vary enough. You know you reach that point when inspection finds patterns of field use or non-use.

Dependency links drive roadmaps and crossteam scaling situations. To work best, you need all crossteam dependent work in one project. dependency linking across projects is akward. Some roadmap tools struggle with arcs showing links across projects.

What should NOT drive the decision is unique wishes for distinct backlogs or boards. Nor should you create a project for each team if they work similarly or on the same product. Projects are not a proxy to issuetype of project or initiative as a shortlived theme of work. Project is not what project managers know as a project. If renamed product, they might understand its purpose.

[Joe Pitt]

Different issue types, different applications, and help desk functions would be logical divisions of projects. It depends on how your teams work. For instance all issue types (bugs, change records, development tasks, etc.) for Application A could be under one project.  If you're using Agile you may want a project just for the development process. You may want to have a change record project that includes all projects if changes encompass multiple applications. If you get to a point where you don't want everyone to be able to see and work on all issues then you'll need to divide the work into projects to manage the permissions.