{"id":5963,"date":"2021-11-09T14:31:31","date_gmt":"2021-11-09T13:31:31","guid":{"rendered":"https:\/\/www.actonic.de\/jira-schemes-verstehen-konfigurationen-im-ueberblick\/"},"modified":"2023-03-29T11:53:05","modified_gmt":"2023-03-29T09:53:05","slug":"understanding-jira-schemes-configurations-overview","status":"publish","type":"post","link":"https:\/\/actonic.de\/en\/understanding-jira-schemes-configurations-overview\/","title":{"rendered":"Configurations overview: Understanding Jira schemes"},"content":{"rendered":"

[vc_row][vc_column][vc_column_text]<\/p>\n

What are Jira sch<\/span>emes?<\/h3>\n

First, a scheme is a concept that has certain characteristics and can be applied to one or more cases over and over again. A Jira schema is a collection of values that can be used by one or more Jira projects. And this is precisely the power of schemes: the configurations you’ve spent a long time fine-tuning only need to be done once. As soon as a next project is created for which your configurations would be best suited, you can apply the created scheme for the new project with just a few clicks.<\/p>\n

If you are an administrator with only a few projects, you may think that you would rather manually configure settings for each project individually. But once you manage numerous projects, adjusting settings manually (afterwards) is a time-consuming task. Jira schemes save time and provide standardized procedures.<\/p>\n

Here you can see an overview graphic we created about Jira schemes:<\/p>\n

[\/vc_column_text][vc_single_image image=”5959″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]<\/p>\n

To better understand the graphic, let’s start at the smallest project unit (on the right) and work our way to the left until we arrive at the largest unit, “Project”.<\/p>\n

Jira Fields<\/span> and Jira Screens<\/span><\/span><\/h3>\n

On the far right of the graphic, you can see “Screens” and “Fields”. When Jira users in your team want to create a new project, they click on “Create” and see a screen similar to this one:<\/p>\n

[\/vc_column_text][vc_single_image image=”5943″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]<\/p>\n

In our view, the fields “Project”, “Issue Type” and “Summary” are mandatory. The “Epic Link” field, on the other hand, is not required to be filled in. This default is not located in the screen, but in the setting of the field, the field configuration (in the graphic we now go one step to the left).<\/p>\n

Field Configuration (Scheme)<\/h3>\n

You can configure the fields as you wish. For each field, you specify whether it is a required field, if you can enter text or numbers, and the overall appearance of the field. You define these settings in the field configuration. They can be put into a scheme to manage fields across multiple projects, issue types, and screen masks. So one scheme can be used <\/span>for<\/span><\/span> <\/span>many cases and saves you from manually creating the layout for each new screen.<\/p>\n

\n

Note: <\/strong>The field configuration belongs to the field itself and not to the screen template!<\/p>\n<\/div>\n

[\/vc_column_text][vc_single_image image=”5937″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]<\/p>\n

Issue Type Screen Scheme<\/h3>\n

In our graphic, we move to the center, to the Issue Types and their schemes. An \u201cIssue Type Screen Scheme<\/span>\u201d establishes the relationship between a project and the available issue types. This ensures that the correct screens are used for each issue type.<\/p>\n

[\/vc_column_text][vc_single_image image=”5961″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]<\/p>\n

In our example, you can see two different configurations with different end results.<\/p>\n

    \n
  1. \n

    Screen Scheme for Story<\/span><\/strong>:<\/span> A story has an arbitrary number of fields, which are created by “create”. When the story is viewed or edited later, exactly the same fields are present as when “create” was used. The advantage of the scheme is that you only need one screen!<\/p>\n<\/li>\n

  2. \n

    Screen Scheme for Bug<\/span><\/strong>: Bug<\/span>, for example, has only five fields in “create” that you can\/must fill in. This is because the person reporting the bug usually doesn’t know very much about it. It may be that he or she is having trouble logging in. Now she can report that an error exists, but there is no knowledge about a known global error (like various IDs or the exact reason). That’s why there is a separate, minimalistic screen for creating a bug. If the bug is edited later, the editor may have 50 or more fields to choose from in the “view” and “edit” <\/span>mode. Here, more detailed information like the description, the status and the exact reason can be recorded. However, these fields are no longer relevant for the person who created the notification. Separating the error message from its resolution speeds up the resolution process immensely.<\/p>\n<\/li>\n<\/ol>\n

    \n

    Attention: <\/strong>You always have “create”, “edit” and “view” to choose from. You alone decide whether there are one, two or three different screens (per task type).<\/p>\n<\/div>\n

    Workflow Scheme<\/h3>\n

    Finally, our graphic shows the configuration of the workflow and its scheme. A workflow defines the sequence of steps that can be taken in a project. Often these steps are: to do \u2192 in progress \u2192 feedback \u2192 done.<\/span><\/p>\n

    [\/vc_column_text][vc_single_image image=”5947″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]The associated scheme places these defined assignments on an assigned issue.[\/vc_column_text][vc_single_image image=”5951″ img_size=”full” alignment=”center” onclick=”link_image”][vc_single_image image=”5939″ img_size=”full” alignment=”center” onclick=”link_image”][vc_column_text]<\/p>\n

    As a Jira administrator, you can link task types with different workflows within a scheme and later apply them to other projects.<\/p>\n

    \n

    Extra tip: <\/strong>All workflows are inactive before they are assigned to a workflow scheme.<\/p>\n<\/div>\n

    Project<\/h3>\n

    A project now takes these schemes (like shoeboxes) and involves all configurations. By having Jira schemes configured, a project gets its specific settings and can be applied to the exact needs of your company or even a single department.<\/p>\n

    This is why you should use Jira Schemes<\/span><\/h3>\n

    If you are a Jira administrator and are bothered by configuration conflicts of your projects and are looking for a quick and efficient solution, Jira schemes<\/span> are the right tool for you.<\/p>\n

    Advantages of Jira schemes<\/h4>\n