Skip to main content

Schemes : Assembling the building blocks of Jira

In a classic Jira project there are building blocks which is required to be created and assembled to onboard a project .Those building blocks like, project, issue types, workflow, screens, permissions and notifications are independent entities. They do not converse with each other.

E.g., 

Team A has created a Jira project as "Legos" and two issue types are decided "Story and bug" to be tracked. The team has also gone ahead and created two workflows for Story and bug. 

Now as these building blocks are created, they are independent, The issue types chosen will not reflect under the project or the issue types will not traverse as per the workflow, because they are not linked to one another

"Schemes" are used to assemble these building blocks. 

Each of the blocks here will have the separate schemes created and integrated. This blog shares details on the concept, creation and linking of each schemes to the project

Issue type schemes

Issue types are the list of items that we would want to track under the projects. When Issue types are created in Jira, the same can be shared across multiple projects. 

In an organisation there may be multiple projects sharing the same Issue types. Hence the list of issue types for a specific project will have to be communicated to Jira via schemes

For e.g., 

Jira project "Legos" is created and two issue types are decided to be tracked. Story and bug. Now these Issue types will have to be linked to  "Legos"

Jira Settings -> Issues-> Issue type scheme -> Add Issue type scheme

Step 1:  Create a Issue type scheme with the name "Legos" It is always recommended to have the project name associated to its respective scheme names. 

Step 2 : Drag and drop the chosen Issue types from "Available Issue Types" to      " Issue types for Current Scheme"

Step 3: Chose the default Issue type for the project.  This default issue type will be the default item chosen when you "Create" a Issue under "Legos" Project. The selection can be changed by the user based on the Issue type he wants to create

Step 4 : Save the changes by clicking the " Save" button below

Step 5: Link the "Legos" Issue type scheme to "Legos" Project

Jira Settings -> Projects-> Manage Projects-> Legos -> Project Settings -> Issue types-> Actions -> Use a different Scheme -> Select "Choose an existing issue type scheme" ->  select "Legos" -> Click "Ok"

And now we have the Issue types linked to the project, with "Story" as default selection

Workflow Scheme

Workflows are the means to communicate the traverse flow of a Issue type to Jira. 

Now that we have chosen story and bug as issue types for Jira, the workflows for these issue types will also have to be created. The process flow of a story will be different from the bug, hence the workflows will also be different. There are three options to link the workflow

1. Create a new workflow

2. Share the workflow which is already designed for another project

3. Copy the suitable workflow from the list and create a independent one

In any case, workflow will have to be linked with the issue types 

In the case of Legos project existing workflow will be assigned for story and new workflow for bug

Jira Settings -> Issues-> Workflows -> Workflow scheme-> Add workflow scheme

Step 1 : Add the name of the workflow scheme for your respective project. 

Step 2:  Click on "Add workflow" to choose the workflow which needs to linked to the issue type. Workflow will be added for specific issue type/ types.

 Select  "Add existing" from the drop down , to choose from the available workflow

Step 3: You will have all the designed workflows listed under " Add existing workflow". Choose the related workflow for your issue type. 

For project "Legos" the team has planned to share the "Default story workflow " which suites there process needs

Step 4:  Now the chosen workflow will have to be assigned to the Issue type. "Default story workflow" is assigned to "Story"

Step 5 :  The same steps to be followed and "Legos bug workflow"  need to be assigned to the bugs

Step 6: Link the "Legos workflow scheme to "Legos" Project

Jira Settings -> Projects-> Manage Projects-> Legos -> Project Settings -> Workflow -> Add scheme / Switch Scheme -> Select "Legos workflow scheme" ->  Associate

Note:

1. Some projects use the same workflow for all the issue types with generic status and transitions. In that case same workflow can be used for all the issue types

2.  If the workflow is shared with other projects, changes to one workflow will have impact on others

Screen Scheme & Issue type screen scheme

When it comes to screen there are two types of schemes, screen scheme and Issue type screen scheme.

Screen scheme 

 Screen scheme is linking the screens to the issue operations like Create, View and Edit.  

There are instances where few information you do not want the creator himself to edit it or a trivial information you do not want to be in the view screen to reduce space. Such customization can be done in screen scheme.

E.g., 

Priority of a Customer defect. Once the priority of the customer defect is added, edit option for the same can be restricted by removing the "Priority" field  from the "Edit" screen associated in the screen scheme

Even if the same screens are planned to be used for all the operations, a screen scheme will have to be created

Issue type screen scheme 

Each issue type will have a screen scheme based on their operations. 

Once the screen schemes for all the operations of issue types is created, the screen schemes are associated with their respective issue types in the Issue type screen scheme

On designing a screen, the first step is to design the screen for issue type and then modify changes for operations. On Implementation the screens are linked to the operations and then to the issue type


Step 1: Jira Settings -> Issues-> Screens -> Screen scheme-> Add Screen scheme

Add a screen scheme for a specific Issue type. The snapshot below is on the  screen scheme for "bug" issue type. Screen schemes will have to be created for each issue type separately

If there are no differences in the screen based on the operations, the chosen screen for the issue type can be selected in the "default screen" field
Step 2:  After you add a new screen scheme, the next step is to associate an issue operation with a screen. To re-insist, this steps are required only if the screen for the issue type changes based on the operation. Otherwise the screen chosen in the default screen will be applied for all the operations

Select the Issue operation and have the respective screen associated. 

Step 3: Related screen for all the Issue operations will have to be added separately.  If there is a modified screen only for the edit operation, then the related screen can be associated to Edit issue, default screen will be auto applied for rest of the operations
Step 4:  Jira Settings -> Issues-> Screens -> Issue type screen schemes-> Add Issue type screen scheme

Now as the Screen scheme is created for bug, next step is to link the screen scheme to the Issue type. If all the issue types are sharing the same screen and if the schemes are similar across issue type the same can be selected while creating the Issue type screen scheme

Step 5: After we have the issue type screen scheme created, all the issue types chosen for the project will have to be associated with the Issue type screen scheme
For Legos we have two issue types, Story and bugs.  The screen scheme already created for the bug is associated with the "bug" issue type

Step 6: Similarly the screen scheme for all the chosen issue types will have to be linked to their respective screen scheme

Step 7: Link the "Legos Issue type screen scheme to "Legos" Project

Jira Settings -> Projects-> Manage Projects-> Legos -> Project Settings -> Screens -> Actions -> Use a different scheme ->  Select "Legos issue type screen scheme" ->  Associate

Field configuration scheme

The steps for field configuration scheme is similar to the workflow scheme. 

Step 1 : Create Field configuration scheme

 Jira Settings -> Issues-> Fields -> Field Configuration scheme->  Add field configuration scheme -> Associate the Issue types and their respective Field configurations

Step 2:  Associate to the project

Jira Settings -> Projects-> Manage Projects-> Legos -> Project Settings ->  Fields -> Use a different scheme -> Select your respective Field configuration scheme -> Associate

Permission and Notification schemes

Permission and notification schemes are not associated to the Issue types. These issue attributes are created as schemes in the first instance and directly  linked to the project

Creating Schemes

Jira settings -> Issues -> Issue Attributes -> Notification schemes  -> Add Notification scheme 

Jira settings -> Issues -> Issue Attributes -> Permission schemes  -> Add Permission scheme 

Notifications / Permissions for the respective projects can be configured directly in the schemes

Link to Project

Jira Settings -> Projects-> Manage Projects-> Legos -> Project Settings ->  Permissions / Notifications -> Use a different scheme -> Select your respective scheme -> Associate

Consolidating

Schemes is an important attribute for a Classic Jira project as it allows sharing. In a Next gen Jira project,  "Schemes" feature is removed as the parameters / attributes of one project is not accessible for others

All the above given steps on creating the schemes are required only when a new configuration is set up for a project. If a project is sharing the existing schemes , then the same can be directly linked to the project. However for any shared instance, change of configuration for one project will have impact across all the linked projects




Labels:

Comments

Post a Comment

Popular posts from this blog

JIRA Screens - Make it better and effective with the What, When and How technique

JIRA - Originally a bug and Issue tracker has evolved into a powerful work management tool.  JIRA is built on a concept that allows users to design their own delivery solution model . Various parameters of JIRA, like workflows, screens, notifications, permissions and so on can be customized to our model Of all other parameters, "Screens" are visible and interactive to the end user. Designing of screens should be more thoughtful to ensure better experience . Sharing you, the WHAT, WHEN and HOW technique for JIRA Screen design WHAT data to collect While you design a screen,  the first step is to understand and consolidate all the information required for the issue type  For e.g. Story Vs Defect Story = Epic details, Story points, effort, Dependencies, Feature,etc., .  Defect = Severity, priority, Affect version, fix version, Impact details,etc., Consider gathering Information from various sources, to ensure maximum coverage. Following are few of the sources which you can refer
8 comments
Read more

Building blocks of JIRA

Jira project on-boarding, in a classic project of Jira there are key building blocks which needs to be modeled and assembled, to ensure successful on- boarding.  Not only for the Jira admin's,it is also important for the end user and requirement givers, to understand the building blocks and their interaction. This add-on will bring in a different perspective on what to expect from Jira. Pictorial representation of how the building blocks are layered is shared below 1. Projects A project in Jira is the level at which you want to track your delivery / execution. A Jira project need not necessarily be the same as your software Project.  Example: You have a project signed for Customer A and you have formed 5 teams: Software, Hardware , Ux, Information development & security team. So now, you can have your Jira project tracked at the customer level or at the team level You can also have a totally independent item, which is not part of your project life cycle, like Organization custo
3 comments
Read more