Page Comparison

Originally developed for tracking software development and bugs, JIRA Jira is an Atlassian application that tracks issues. It is flexible enough to be adapted to any process that follows a workflow.  It is a powerful collaboration tool that allows us to follow processes across and between platforms, enhancing information dissemination at the Broad. (And cutting down on email!)

Due to JIRA’s customizable nature, we’ve been able to develop different projects for multiple processes at the Broad including:

• Help Desk for support issues (example: Crazy Robots for requesting lab equipment maintenance.)
• Process JIRA for tracking units of work within a process (example: Tracking one set of libraries in LCSETs)
• Lab Notebooks, where individuals can track their experiments from design through conclusions. (example: DEV and CELL)

• GP software support
• Lab automation asset/request tracking
• Product order tracking
• Production sample batch tracking
• Lab notebook for development experiments

JIRA has several key objects:

• Issues – the unit of work that we want to track (ex: one library set, one flowcell, one experiment). Interchangeable with ‘ticket’. JIRA gives us the ability to create custom issue types , for example each type of library has its own issue typefor easier queuing in the lab.
• Project – the highest level of groups of issues in JIRA. Every issue must belong to a project. Each project must have a unique key, and this is how people most often refer to an issue. Example – “I did an experiment looking at density, which is described in DEV-905.” DEVis the key for the Process Development project.
• Fields – the areas within an issue where data is captured. For example, “Summary”, “Hypothesis”, or “Number of Samples”.
• Status – The process step state the issue is currently in. (e.g, "Closed", "In LC".) Resolution – A resolution is different than statuses in that this field tells you the ultimate result of an issue. Issues are finalized with a ‘closed’ status, whereas some could have a ‘Completed’ resolution and others would have a ‘Reworked’ resolution. Both will be closed, but resolution tracks how it got there. This specific example is from the flowcell tracking project when we want to rework failed flowcells.Super customizable based on issue type - for example an instrument has a "Down" state, and LCSETs have a "Ready For Sequencing" state.
• Transitions – the pathways to advance or return an issue to a particular status. Lab automation is increasingly transitioning tickets automatically based on deck events.
• Workflows – the predetermined (by the lab and LIMS) set of statuses and transitions an issue goes through. 
• Resolution – Issues are finalized with the ‘Closed’ status, but resolution tracks how it got there. For example in the Cell Line Factory project, one issue is one cell line. A 'Closed' CLF ticket for example could have a resolution of 'Terminated' if the cell line did not grow, or 'Validated Tumor' if the cell line was validated as a tumor.

System Architecture

We have multiple two main JIRAs (known as instances) in use in the Genomics Platform:.

• LabOpsJIRA (labopsjira.broadinstitute.org) - Our main work horse for tracking most lab production processes as well as lab automation inventory and request tracking.
• CRSP JIRA (crspjira.broadinstitute.org) - Structured similar to LabOpsJIRA, but tracks processes within our more tightly regulated Clinical Research Sequencing Platform (May show up as link broken if you don't have permission to view.)
• GP Informatics JIRA (gpinfojira.broadinstitute.org) - A more 'traditional' JIRA, used for requirements tracking, bug tracking, support requests and feature requests for our Informatics teams. See their confluence page here.Collaboration JIRA (colab.broadinstitute.org) - An external facing JIRA to allow GP team members to collaborate with external vendors and teams. (defunct as of March 2016)

Each Jira has a production and a development instance. LabOpsJIRA has a special integration instance that we use for testing against LIMS changes.

Filters/Searching

Saved searches are known as filters and can be shared with other users as well as subscribed to. (for example our Illumina service team gets a daily email of all open issues.)

At the top navigation bar in Jira, click Issues → Search For Issues

There is a basic search where users can pick search criteria from dropdown fields.

TIP: It really helps search performance if you always select your relevant project/s first!

Image Added

And there is a more powerful advanced search that gives many additional functions not possible in the basic search, like the ability to search within linked issues and the ability to have multiple conditions.

Queries are written with a language called JQL (JIRA Query Language) - this is very similar to SQL.

Image Added
JQL is used in other analytics tools, such as our homegrown JQL -> TDE tool that allows Tableau to use a saved JIRA filter as a data source.

Dashboards/Agile Boards

Users have a couple ways of seeing their work at a glance.

Dashboards are pages that users can customize with gadgets. E.g display saved search results, show project statistics (like who has the most open assigned issues). Saved filters are a required first step for many gadgets - unfortunately JIRA doesn’t let users make up searches on the fly.

Dashboards also have activity streams where you can see what tickets others have made or commented on.

Agile Boards are interactive pages where you can drag and drop cards into relevant columns, and can also slice and dice cards based on swimlanes. Swimlanes can be configured by assignee or other customized groupings like issue type or lab protocol.

Granting access to JIRA (Admin Use)
Adding new Illumina Instruments to JIRA (Admin Use)
Updating Instrument ticket summary (Crazy Robots) (Admin Use)