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 customer satisfaction survey, Certification audits, any improvement initiatives and so on

"Create" a project

Jira -> Settings -> Projects -> Manage Project -> Create Project

2. Issue types :

The next step after project creation is to decide on the Issue types

• Issue types are the list of items that you need to track and monitor for a Jira project.
• Issue types are mapped to their associated projects and the same issue type can be mapped to different projects

There are two JIRA issue types

A. Issue type 

This is the generic issue type, where the decided items to be monitored and tracked for a project is listed. For a software project , 

• An issue type can be the input for your delivery ( Requirements, Epic , Story ) or 
• The deliverable's ( Design, Defect, RCA). 

Both can be tracked together as well

"Add" an Issuetype

Jira -> Settings -> Issues -> IssueTypes -> Issue Types -> Add Issue type

B. Sub task Issue type

This issue type can be the logical smaller pieces of the generic issue type itself or the to - do list to move the generic Issue type to closer

Example

When "story" is a Issue type, the subtask can be 

a. Story broken down further :- Scenario 1, Scenario 2, Scenario 3

b. To-do list to close the story : - Coding, review, Unit testing, Static Check , Test design, Test execution

"Add" an Subtask

Jira -> Settings -> Issues -> IssueTypes -> Sub-tasks -> Add sub-task Issue type

Note  - 

1. There is no category of Issue type as "Task" in Jira. It can be one of the Generic issue type or Sub- Task
2. Sub- task once created will be automatically linked to the parent Issue type

3.Workflows

Workflows are instructions you give to Jira on how to traverse the Issues from Create to Closure

• Workflow is associated with both the Issue types generic & Sub- task
• Workflow can be designed in "diagram" or "Text" mode

Status and transitions are the two parameter's used to design the workflow

Status and Transitions

Status  - Gives you information about the current situation of an Issue

Transition  - A means to move your Issue from one status to another

Transitions are like buses with different route numbers and status is the destination that you reach on each route. Each transition will move the issue to a different status.  

Example: 

A defect is logged by the tester and it is assigned to the developer. The current status of defect is "Open". 

From this status the possible transition and related status for the issue is shown below

"Add" an Workflow

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

4. Screens and Fields

Now we have the Project, issue types and also the workflow. Next is to build the framework to collect the information. 

Screens - Screens can be associated to each transition of the workflow and also to the different operations in a Issue type like create, view and edit

Fields - There are already a set of Jira created system field which can be used for the screens. Also custom fields can be created to add in the required data

Screens and Fields created can be associated with any number of workflows / projects. However changes to the field options or screen list items will impact all the workflows

"Add" Screen

Jira -> Settings -> Issues -> Screens -> screens -> Add screen

"Add" Fields

Jira -> Settings -> Issues -> Fields -> Custom Field -> Create custom field

You can refer my earlier blog to get more information on designing the screens and fields

5. Permissions and Notifications

Permissions and notifications are linked to the Projects. Same configuration of permission and notifications can be used for multiple projects

Permissions : 

Under permissions, the user actions that can be performed on the issue is controlled

There are different levels of permissions

- Project, Issue, Watchers, Comments, Attachments, Time tracking

"Add" Permission scheme

Jira -> Settings -> Issues -> Issue attributes -> Permission schemes -> Add Permission scheme

Notifications : 

- Informing Jira about the event on which E-Mail should be triggered and to whom 

- Notifications can be triggered on different events to different users

"Add" Notification scheme

Jira -> Settings -> Issues -> Issue attributes -> Notification schemes -> Add Notification scheme

  Consolidating

This brief detail on the building blocks will give in a basic understanding on how things work in Jira. On-boarding a project into Jira can also be done as a Next gen type if you are a cloud user.  

There is always more to learn in JIRA, Share in your views and experiences in JIRA designing. In the blog up here I have just shared few sample scenario's, for any support on specific JIRA screen design or any other JIRA activities do comment in. Look in this space for more sharing's related to JIRA

Did you know ? 

- JIRA has a special product for Juniors

   JIRA Jr. - https://www.atlassian.com/jirajr