Are You Using AI In Your Job?

We want to understand the real-world applications of AL and ML in business and the impact it will have on all our jobs.

Want to help? Complete the survey, your insights could make a big difference. It will just take one minute.
You'll be the first to get access to the final report.-->

Using JIRA For Mobile App Development

Bobby Gill | February 5, 2020

Despite its many warts, JIRA is a more than capable issue management tool ideal for managing software projects of various types and team sizes, including mobile app development.

Part of JIRA’s power, and I would imagine the reason behind its insanely complex configuration UX, is that it is flexible enough to adapt to the nuances of each team that uses it and the project it is being used for.

At Blue Label, our team has developed over 200 mobile apps and through all that I’m proud to say we do not subscribe to any particular development dogma or methodology.

Instead, over the years we’ve developed a mobile app development process that is the son of  1000 Agile fathers, one that borrows heavily from different frameworks and which we adapt based on the client and project we are working on.

However, one thing that remains constant is how we use JIRA as the central point of management of our mobile app development process, from specification to sprint planning, from bug tracker to release management, JIRA is our main tool to coordinate our engineering efforts.

Setting up JIRA: decide on the workflow

One of the first things any organization needs to choose when setting up JIRA workflow for software development for the first time is the “workflow” they would like to use for issues in JIRA.

The “workflow” is essentially the set of statuses and transitions between those statuses that any issue in JIRA might travel from birth to completion.

Issues can be anything from user stories such as…

“A logged in user should be able to reset their password using only their email address”

to very specific bugs like…

“App crashes when user attempts to login with hyphenated email address”.

At Blue Label, our JIRA workflow is very complicated and has many different transitions which aren’t always used on each project.

As a software development agency, we have to adapt our use of JIRA to fit the client we are working with, and something that is critically important for a Fortune 500 client might add little value to a small startup looking to get its MVP out the door.

So much like a brown bear caught on a glacier, we adapt.

Here is a very brief look at our JIRA workflow and the relevant statuses and transitions that are common to all mobile app development projects we run:

  • Open
    • All issues are by default opened in this state and remain so until triaged by a PM.
  • Selected for Development
    • Issues are moved here when, as the name would imply, the Issue has been triaged and approved by the PM to go to development.
  • In Active Development
    • Need I say more?
  • Dev Smoke Testing
    • Issues are moved here by engineering only when the work itself is complete and unit and smoke tests run by the dev team pass.
  • Ready for Testing (QA Team)
    • Issues in this state are ready for formal verification by the QA team and for final resolution. Issues in the “Ready for QA” pile are deployed in the testing environment where QA is able to properly verify them and perform regression testing.
  • Verified (by Internal QA)
    • Issues move here after the QA signs off on them. However, they don’t immediately move to a Done state, instead they stay here until the PM verifies User Acceptance Testing (UAT) has passed and that the Issue is truly and completely resolved.
  • QA Fail
    • There are few things more frustrating to a PM then a developer saying they fixed a bug when they really didn’t. This status indicates that a Issue needs to return to engineering and also serves as a cathartic outlet for the frustrated sighs of many a PM.
  • Blocked
    • Issues land here when they cannot be worked on due to an external dependency.
  • Done
    • Finally, after an often long and tortuous journey, Issues arrive here to live in eternal rest once they have been fixed, tested and deployed.

To sum up

While the above might sound a little complex and ambiguous, it reflects a process that has emerged in our organization over the more than 200 projects we’ve completed in the past decade.

The important thing to take away is that no two mobile app development projects are the same. As such, our JIRA workflow for software development has to adapt to the particular nuances of a project and client while at the same time retaining a core set of central principles which can allow any member of our team to jump in and work on a project.


Bobby Gill
Co-Founder & Chief Architect at BlueLabel | + posts

Get the latest from the Blue Label Labs’ blog in your inbox


* indicates required