Skip to main content

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


Labels:

Comments

  1. sivaAugust 7, 2020 at 11:14 PM

    Very informative!!

    ReplyDelete
  2. KrishnaAugust 8, 2020 at 2:20 AM

    What about creating Dashboard?

    ReplyDelete
    Replies
    1. Prabha SasikumarAugust 8, 2020 at 2:58 AM

      This blog is focused on the initial building blocks to get Jira up and log issues. So dashboard is not included. Dashboard will be as part of Monitoring and Reporting.

      Dashboard majorly works on 3 different data : Projects, boards and Filters.
      Once the initial set up ( as in the blog) is done in Jira, the next step will be is to configure the boards and create filters. Using the appropriate gadget with this data, the dashboard can be created

      Delete

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 c...
8 comments
Read more

Software Process and Covid - 19

During this pandemic, WHO and other government bodies have been giving guidelines and instructions to ensure our safety. Most people read thru these guidelines, some understand, few follow and less adhere. Even with the lesser, the effectiveness is questionable because, the guideline is just followed. With 14 years of journey with process, can't help but compare the current scenario with "Process compliance" in Software Quality Process Compliance Mishaps Process is Taken in by the team irrespective of the fitment Followed strictly (only) for sample releases to showcase it to the certification auditors Felt as an unnecessary, forced add-on to the delivery cycle An effort drainer for the software engineers Used as a weapon by senior management to punish the mistakes Do not follow Process Focus on the Process intention than the guideline - Like, review is to identify the defects early, do not focus on meeting the org target Process should be seamlessly integrated to delivery...
Post a Comment
Read more

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 ...
1 comment
Read more