Jira Project Setup Basics

[#1]

So two years ago I started my journey into Atlassian Products. However, resources for Atlassian products are all over the place. While Googling is an immensely useful tool, sometimes a quick reference guide is just what the doctor ordered.

The following article goes over what each component is that Jira requires to setup a project, and some optional ones as well. It was designed to help both Admins and users alike. All relevant documentation has connected links, creating one unified resource.

However, it is not a best practice guide. If you want to learn about best practices I would highly recommend @Matt Doar book: Practical JIRA Administration: Using JIRA Effectively: Beyond the Documentation. In addition, there are many articles posted on the Community as a whole. If you do not see what you are looking for, always feel free to ask!

Jira Project Concepts

Schemes

Jira uses 8 different scheme sets in Data Center, and 7 in Cloud, to control how a project functions. Below is a list with short definitions. For a project to work, all are necessary. Jira contains default ones for certain cases. The default ones appear when using templates, including Kanban or Scrum. These options appear when one clicks "Create Project"

Jira contains options for most Schemes list not having capabilities for Issue Type configuration**. Advanced workflow configurations allow most of these. Advanced workflow configuration should be kept to a minimum. An alternative is Automation for Jira. Depending on the version of Automation for Jira, users have a more clear view of why something works or not. 

This article relates more to Jira Data Center and Jira Cloud Classic Projects. Some of it may apply to Next-Gen, though, it was not written with that intent

Issue Type Schemes

Issue type schemes determine what issue definitions a project allows. For example some projects may use Tasks and sub-tasks. Other projects may also allow use of Epics, Stories and Bugs, also. 

Workflow Schemes

Workflow schemes determine how a certain issue type moves through a project. A project may use 1 workflow for all issue types or have separate ones for each. For example a Task could have a workflow of To Do->Doing->Done while a Bug may have a workflow of To Do->Doing->In Review->Done

Screen Schemes

Screen schemes determine what fields show up on a given Issue Type. Jira comes with a small subset of fields out of the box i.e. Summary, Description, Fix Version etc... It turns out, most fields are Custom Fields. Check Screen schemes when fields do not show up for different actions. This includes on creation, edit or viewing of a screen. Jira has a great built in tool for this too. 

Field Configuration Schemes

Field Schemes determine what fields require completion within a given project. They also determine the definition of the field itself. Take for instance the field Story Points. Some projects may show a definition of "1 Story Point=1 Day". Another project may define it as "A Unit of Measurement for Difficulty of an Issue". When a screen requires a field that it should not, this would be the first place to check. 

Priority Schemes

Priority Schemes determine what a project defines as its priorities. While some people may prefer something like High, medium, Low to define how urgent an issue is, others may use major, Minor, Trivial. Priority schemes define this per project. Only one Priority Scheme is allowed per project, they are not tied to Issue Types like some of the other schemes.

Permission Schemes

Issue Security allows marking specific issues with a more limited viewing than others. It works in tandem with a Permission Scheme. It limits a user's insight beyond a Permission Scheme. For example, a project may track bugs and new features. Bugs may allow all users to view them. However, features should only allow developers to view them. Issue Security allows this type of scoping within a single project. Jira allows one Issue Security Scheme per project. They are not tied to Issue Types like some of the other schemes.

Issue Security Scheme

Issue Security is a scheme that allows for individual issues to be defined as more secure than one another. These can be used to limit who has view access beyond a Permission Scheme. For example, a Project may be used to track bugs from users and also includes new features that are going to be released. While the bugs may be viewable to everyone so people are aware of potential application issues, new features may only be viewable to the Product Team working on creating the new features. Only one Issue Security Scheme is allowed per project, they are not tied to Issue Types like some of the other schemes.

Notification Schemes

Notification Schemes determine who receives what notification based on what action is occurring. Examples of this include when an Issue is closed, transitioned or commented on. Settings for notifications can be set for Current Assignee, Reporter, Current User, Project Lead (Jira Admin Controlled), Component Lead (Project Admin Controlled), Single User (Jira Admin Controlled), Group (Jira Admin or Directory Controlled), Project Role (Project Admin controlled), Single Email Address (Only works if email address being used would have view access to the issue), All Watchers or Custom Field Values (Anyone who has edit access to the issue can update these). For a user to receive a notification they must have view access to the issue as defined by the Permissions Scheme and Issue Security Scheme. Only one Notification Scheme is allowed per project, they are not tied to Issue Types like some of the other schemes.

Implementing Schemes 

Below are some useful links for creating different objects within Jira

Create Issue Type Data Center Cloud

Create Issue Type Scheme Data Center Cloud

Create a Custom Field Data Center

Create a Screen Data Center Cloud

Create a Screen Scheme Data Center Cloud

Creating a Field Configuration Scheme Data Center Cloud

Creating a Priority Scheme* Data Center

Creating a Permissions Scheme Data Center Cloud

Creating an Issue Security Scheme Data Center Cloud

Creating a Notification Scheme Data Center Cloud

Project Specific Parts 

Components

Components are a per project way to define work, or separate the work out. If one does not need to separate work out with components, another use is a project custom field. Components are also a way to assign work automatically, outside of Project Lead or assigning via automation (Automation for Jira, Scriptrunner, or Workflow).  If one wishes to use them in Automation for Jira list maintenance is necessary. Maintenance includes adding new ones and merging or deprecating unused ones. This will allow Automation for Jira to work without missing data.

Versions

Versions are a way to define when to release work. Project Admins control them. If one wishes to use them in Automation for Jira list maintenance is necessary. Maintenance includes adding new ones and merging or deprecating unused ones. This will prevent Automation from Jira from not being able to see certain versions.

Utilizing Components and Versions

Managing Components Data Center Cloud

Managing Versions Data Center Cloud

*Not currently a feature within Jira Cloud

[Tanya L Christensen]

Thanks for this. It's a quick summary with good links. I've passed it to my support team, some of whom are quite new but tasked with helping our users with their scheme changes.

[Clark Everson]

@Tanya L Christensen that's great! I am glad to hear it helps!

[John Funk]

@Clark Everson  - excellent summary - thanks for sharing!

[Kalin U]

@Clark Everson Great overview. Thanks for taking the time to write and share it.

The Priority Schemes do pertain to Data Center only. Bringing them to Cloud is still one of the top voted requests as of July 2022 with more than 4000 votes.