Jira best practices: Creating projects and workflows

This is part of a blog series with our own tips on configuring your Jira, maximizing your use of Jira's many features, and tailoring the platform to best suit your organization’s needs.

Creating Projects in Jira is really simple; however, there are some things you should have in mind when creating a new Jira project. Depending on how your organisation uses Jira, you you might be creating Jira projects frequently or not so often. For example, a professional services company might create a separate Jira project for each of their customers, whereas a product development company might create a Jira project for each product or department (e.g. Marketing, Development, or Support).In this blog, I'll go over some of the best practices when creating Jira Projects, and related Schemes, that will make administering Jira easier.

Creating a Jira Project

When you create a Project in Jira you can select from different types of project templates, for example Service Desk, Simple Issue Tracking, Agile Scrum and Jira Classic. These project templates might make the setup of your project faster and easier, but there are some major drawbacks to using them. When you use some of these templates, Jira automatically creates various schemes like Workflow Schemes, Issue Type Schemes etc., whose properties might hinder functionalities of various add-ons. These schemes will also, as the number of projects grows, clutter your administration pages, become confusing and make administrating your Jira instance more complex and time consuming.

We strongly recommend using the Jira Classic project template. The Jira Classic template does not create any schemes but instead uses the Jira Default Schemes. The Jira Default Schemes can then be replaced with your own schemes, if desired. Re-using the same schemes where possible keeps your Jira instance more simplex and easier to manage.Before you start to create new Jira Projects, we recommend that you decide on a naming rule for your Projects, both Project name and Project keys. It's a good practise not to use too many letters in your Project keys and have some system regarding the Project names. An example can be never to use more than 5 letters as a Project key, and a Project naming rule for a multi-national company could be: Product + Department + Country => Product Support Germany.

To highlight this argument, let's look at three different examples:

Simple Issue Tracking Project Template

When you use the Simple Issue Tracking template when you create a new Jira Project, Jira creates a new Issue Type Scheme and a new Workflow Scheme for the new Project. The Schemes have the Project Key in it's name, example "SIM: Simple Issue Tracking Workflow". When you create your next Simple Issue Tracking project another Simple Issue Tracking Issue Type Scheme and a Simple Issue Tracking Workflow Scheme is created and conveniently named the same, except the Project key changes.

Project Created in Jira Agile

When you create a new board in Jira Agile, you can create a new Jira Project in the process. When doing that, Jira creates Issue Type Schemes and Workflow Schemes for the new Jira Project. This is the same behavior as described for the Simple Issue Tracking Project Template, but the naming rules that Jira Agile uses is different.

Project Created in Jira Service Desk

When you create a new Project from Service Desk, JIRA creates a new Issue Type Scheme, Workflow Scheme, Issue Type Screen Scheme and a Screen Scheme. This is similar to the behavior described above, but more Schemes are created.When the number of projects grows differentiating between all these schemes becomes really difficult. And if you want to change some functionality in a workflow for example, you will need to change multiple workflows instead of just one if you use the JIRA Classic project template and re-use the same workflow scheme.

Creating Workflows and Workflow Schemes

When creating new workflows in JIRA, you have the possibility to copy an existing workflow or create a new one from scratch. When you copy an existing workflow be aware of the fact that the workflow might have some conditions, validations, post-functions or properties that you might want to delete from your new workflow.When creating a new workflow we strongly recommend to keep it as open and flexible as possible. Use a descriptive name for your workflow and don't add conditions, validations or other functionality to your workflow unless you really need to.The next step is to create a workflow scheme for your project. A workflow scheme allows you to use multiple workflows in a single JIRA project, where the issue type controls what workflow is used.

Other Schemes in JIRA

Like mentioned above, all JIRA projects have various schemes. It depends what JIRA Project template to choose, what Schemes are associated to the JIRA Project. Every project has several schemes, some scheme types are required and some are optional. The following is a list of all project scheme types in JIRA:

Issue Type Scheme (required):

Allows you define what issue types can be created in the project. This can vary between projects and we recommend never to use the default issue type scheme.  The reason is that all issue types in your JIRA instance are included in the default issue type scheme.

Workflow Scheme (required):

Allows you to link multiple workflows to your JIRA project, one for each issue type if desired. Remember that the default workflow scheme might have some functionality that you don't want.

Screen Scheme (required):

Allows you control what fields are used for each screen and what operation the screen is linked to. Screen Scheme is then associated to an Issue Type Screen Scheme, where you associate a screen scheme to an issue type. Screen Scheme is not associated to a JIRA Project directly, but via the Issue Type Screen Scheme.

Issue Type Screen Scheme (required):

Allows you to associate a Screen Scheme with an Issue Type.

Field Configuration Scheme (required):

Allows you to control what fields are required and what fields are optional. This can vary between JIRA Projects and the Field Configuration Scheme makes that possible.

Permission Scheme (required):

Is used to control the permissions for each JIRA project. We recommend using Project Roles in the permission Scheme, to make it easier for Project Administrators to control the JIRA Project access through Roles in JIRA Projects.

Issue Security Scheme (optional):

This is an optional scheme and is used when you want to control access to some issues within a project.

Notification Scheme (optional):

It is optional to use a notification scheme, depending on whether you want to send email notifications or not. When creating a new Notification Scheme, we recommend that you create a new notification scheme and select options according to your needs.I hope this blog explains what we recommend as best practices when it comes to creating Jira Projects and the different Project Schemes. This is built on our several years of experience in managing Jira instances for ourselves as well as our customers.