JIRA Best Practices: Creating Projects and Workflows

Best PracticesRead in 6 minutes

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 (Version 6.3 used in this blog) 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.

create-jira-project

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 behaviour 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 behaviour 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 wether 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 practises 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.

Tempo_partners_logo

About Sandra

Sandra is Tempo’s Channels Manager and an Atlassian Expert in Iceland who consults with a variety of companies on setting up and getting the best use out of Atlassian products for their organizational needs.

Find a Tempo Partner

References

Related Posts

8 Responses

  1. Matt Doar says:

    Good guidelines! I would also recommend using project categories

  2. AnLeBe says:

    Hi!

    Thanks for setting up this guide.

    Can you tell us what is your experience with using Agile boards (Scrum or Kanban) with JIRA Classic Projects? It is possible… but also recommended?

    Thanks and regards!

    • Bjarki Bjarki says:

      Hi AnLeBe,

      We recommend using JIRA Classic when creating new Projects in JIRA because by doing that you can use Schemes that you have already created.
      When using other Project templates, JIRA creates new sets of schemes and makes it more difficult for you to manage.
      You can use JIRA Classic with JIRA Agile. You just need to make sure that there is nothing in your workflow forbidding you to transition issues.
      I hope this answers your question.

      Best regards,
      Bjarki

  3. Dominic says:

    Hello. You had mentioned a professional services company might create a separate JIRA Project for each of their customers. Can you provide more info on how this setup might be achieved? Are there any benefits in setting up client specific projects in JIRA? Are there any downsides to setting up client specific projects in JIRA?
    Thanks!!

    • Steinunn says:

      Hi Dominic

      Yes in our experience this is very common – companies create separate JIRA projects for each of their customers. The main reason for doing this is giving the customer access into their project within JIRA. If the customer is big and has many projects and issues, companies can make a project category for that particular customer and group all customer projects together. By doing this, the customer becomes a JIRA user within their instance, and the company needs a bigger license tier. E.g. if a company has over 1,000 customers, the license cost is greater. The downside is mainly the daunting task of managing all of the projects as the JIRA admin, if there are hundreds of open projects. I hope this answers your question, otherwise please don’t hesitate contacting us again.

      On that note I would like to recommend you take a look at our professional services solution for JIRA, Tempo Books. Tempo Books is a billing workflow management and customer budgeting for JIRA. There you have your customer portfolio and account overview as a gateway to attain more information about each customer and associated accounts. Tempo Books allows you to oversee the people involved, teams, and projects more easily. We’re having weekly walkthrough demos of our products and next week we’re hosting Account Management demo using JIRA, Tempo Timesheets, and Tempo Books if you’re interested.

      Best regards,
      Steinunn

Leave a Reply

Plan, Budget, Track & Adapt with Tempo for JIRA.


Subscribe to our blog

Get the latest posts delivered to your inbox:

Thank you for signing up!

Please check your email to confirm your subscription.

Select the Tempo products you'd like to hear about:

Tempo Planner Tempo Budgets Tempo Timesheets