The Dev Toolbox: Jira Part II

March 19, 2015

Blog | Technology | The Dev Toolbox: Jira Part II
The Dev Toolbox: Jira Part II

Welcome back to The Dev Toolbox! Today, we’ll look at the building blocks of the Jira system: Projects and Issues. (This is a follow-up to my introductory post about Jira.)

The Dev Toolbox: Jira Issue & Project Tracking

According to Atlassian’s documentation, a JIRA Project is a collection of issues, defined according to your requirements. For example, a project could be:

●      a software development project

●      a marketing campaign

●      a helpdesk system

●      a leave request management system

●      a website enhancement request system

When an administrator adds a team member to a project, a project role is also set that enables them to fulfil a particular function in that particular project. Likewise, admins can determine which team members can see which projects as well as provide different field options for Issues from within another project and basically, represent a group of work.

Below is an image of an example Project landing page, displaying the full breakdown of all Issues within the project and the allocation between team members.


With Issues, Jira offers more granularity and control. For instance, Issues themselves are defined with multiple subtypes and each of these subtypes can have its own workflow within the system.

Internally, we have the following types of Issues.

–       Epic: A big user story that needs to be broken down.

–       Bug: A problem which impairs or prevents the functions of the product.

–       Inquiry: A question, generally more complicated, which requires research.

–       Internal: Bucket for logging time against for internal tasks for GeekHive.

–       New Feature: A new feature of the product, which has yet to be developed.

–       Story: A user story Task A task that needs to be done.

Since Jira supports Issue hierarchy, there are also the following subtypes for issues residing beneath other issues.

–       Defect

–       Sub-task

–       Technical task

Beyond this, Issues can also be grouped by priority.

–       Blocker: Blocks development and/or testing work, production could not run.

–       Critical: Crashes, loss of data, severe memory leak.

–       Major: Major loss of function.

–       Minor: Minor loss of function, or other problem where easy workaround is present.

–       Trivial: Cosmetic problem like misspelt words or misaligned text.

You can also define a specific workflow for Issues. For instance, the below image shows the transitions supported by one of our most basic workflows:

Workflows are helpful to the development process because they turn the problem-solving process into a type of assembly line.  A programmer can complete his or her work, and send it down the line for the next team member to do his or her job.  It increases productivity and allows team members to specialize in things they do well or enjoy.

The workflow can be customized as needed, as shown by this more complex workflow:


The Agile board, a plugin that we rely on for the majority of projects, allows for the team to use the Agile methodology. As shown below, it board consists of Plan, Work, and Report sections that each serve a different purpose.

The Planning interface is used to track work prior to the commencement of a Sprint. By adding items from the Backlog into the Sprint, we can define what will be completed for the next milestone and what will remain to be completed for subsequent milestones.


The Work interface shows developers what tasks are expected to be completed during the current Sprint. The To Do, In Progress, and Done swimlanes represent the status of each ticket. Note that the number and names of the swimlanes shown for a particular Agile board can be customized to be as granular or as high level as desired. It also fully supports sub tasks, so that the parent task can remain In Progress while some of its sub tasks may have transitioned into the Done state.

Finally, at the end of a Sprint, the Report interface helps provide a summation of the work completed (as expected) versus what work may not have been fully completed. In our example, the Sprint has just begun, so (rightfully so), the burndown is currently flat.

Comprehensive reporting is great news for clients!  Reports can help manage budget, demonstrate progress, or aid in the planning process.  The Agile methodology is all about measuring things, and these reports turn those measurements into milestones for success. Note: to main our clients’ confidentiality, a sample burndown chart is being shown. For more details on this feature, please see the Jira Agile documentation.


And now, off to the races! Let us know @GeekHive if there are any other aspects to the Jira system that you’d like us to review!


Phil Azzi, Developer, GeekHive

Phil Azzi

Technical Lead
  • Productivity
  • Project Management

Recent Work

Check out what else we've been working on