IRA is a proprietary project management and issue tracking tool developed by Atlassian. This software was originally designed to be a bug tracking tool, but in the last two decades, it has evolved into a family of products that can help manage the work of all kinds of teams.

When I started my career in the localization industry as a video games localization quality assurance tester in June 2008, I was reporting localization and system terminology issues. We were using many different bug tracking tools, like Microsoft Product Studio, MantisBT, and TestTrack Pro.

I really loved these kinds of software for three main reasons: structured and organized information; permanent searchability; and the possibility of cooperation. I was exposed to JIRA in 2012 for the first time, during a substantial company wide reorganization, and it was pretty much forced on me and my team.

A workflow in JIRA.

Are work management tools like JIRA an unnecessary extra step?

In 2012 I was a producer for a free-to-play MMORPG (massively multiplayer online role-playing game) with six million users, six markets, and millions of dollars in annual revenue. A good portion of my team, composed of linguists, community managers, quality assurance testers, customer support, and marketers, were not impressed with JIRA. They saw it as an unnecessary step in an already-busy and frenetic workday.
I was likewise surprised by this decision from above, and having to move all our day to day production activities was a huge time investment. I could not see why a bug/issue tracker like JIRA could help us manage the very complex lifecycle of an MMORPG.

JIRA adoption was strongly sponsored by my then-CEO, and by managers more experienced than me. They were relentless, and JIRA was adopted pretty much in the whole company.

In this instance we were using JIRA with the following high level organization:

1) Project: a specific video game and team in support.
2) Task: daily or weekly activities; for example, preparing “security awareness” campaigns across all markets.
3) Sub-Task: a specific step to achieve the higher-level goal. For example, for the French version of the security awareness campaign, “Create list of accounts that have reported security issues.”

At first, my whole team complained about the substantial extra time investment required to create Tasks and Sub-tasks, fill in all the fields in JIRA like goals, due dates, financials, work owners, and so on. Then we became more and more familiar with the tool and realized that we could recycle much of the original transition work via cloning and template creation. Misunderstanding and confusion caused by half-baked kick-off emails and chats was decreasing, and project information became more permanent and easy to access — even by team members in other office locations around the world.

The data entry step was forcing all of us to think more, plan more precisely, and offered work visualization support that facilitated meetings and brainstorming.

My CEO and managers were right, and I was wrong to resist this change. I also realized how much time I was saving when checking project statuses at a glance via JIRA dashboards and gadgets.

Teams that previously were working in silos now had a tool that facilitated cooperation. Key operations teams across the organization were now constantly sharing information and were aware of initiatives as soon as they were kicked off.

Our productivity, our sales, and our reaction time to challenges faced by customers improved. These improvements were achieved because it became much easier to avoid delays caused by miscommunication, lack of information, and risks that materialized at the last moment.
An unplanned positive side effect was that all that data that was entering JIRA every day also helped us understand key performance indicators (KPIs) that were previously escaping us.

The only regrets that I have in this JIRA implementation experience are, first, that not all teams in the company joined JIRA. Billing, IT, legal, and HR were not accessible. This more than once caused conflicts, delays, and miscommunication. Second, I wasn’t very familiar with JIRA plugins and the incredible potential offered.

Quantifying active JIRA projects.

The power of plugins and queries management

My second JIRA implementation experience was in the summer of 2015, this time in a very promising machine translation start-up. We had a small team, and there I had to be the JIRA administrator as well.

We were facing a large and complex project involving ChemZent (a product of CAS, a division of the American Chemical Society). We had to digitize, translate, and index 140 years of German journals and patents (Chemisches Zentralblatt). In this context I had the chance to discover the power of JIRA plugins.

Because of the highly complex nature of this project, the small pool of resources and the aggressive timeline, we had to pay special attention to work breakdown structures and to “critical path” analysis.

In this instance, we were using JIRA with the following high level organization:

1) Project: A specific request from a client or a phase of a larger project.
2) Task: A part of the planned outcome/goal.
3) Sub-Task: A piece of work to obtain a part of the planned outcome/goal.

It didn’t take me long to find what I was looking for in the Atlassian MarketPlace and in a few days, we managed to really upgrade and enable some particularly useful functionalities.

I loved the plugin “Workload” to visualize workload and manage capacity, “Fiesta” to manage team calendars in sync with capacity, “Backbone” to sync Jira issues across multiple Jira instances, and a plugin to draw critical paths that unfortunately I can’t recall the name of, something similar to Artezio Path.

As a technical project manager during this experience, I also learned that it is important to invest time and resources in creating a solid workflow in JIRA and take advantage of JIRA’s Transitions in order to unlock automation potential.

During this project, which lasted about a year, we were facing a high number of daily queries that were very complex in nature (go figure; it was machine translation from German to English of OCRed chemical patents from 1830 to 1969). We ended up creating a restricted JIRA project where our client could access and cooperate with us in query resolutions.

Our productivity and clarity of operations improved substantially between the first iteration and the improved implementation of JIRA. In my experience the real force amplifiers were well thought out tasks; KPI tracking; and far superior risk management.

The JIRA calendar showing the number of issues in active projects.

JIRA at the service of a localization team in a large organization

I joined HubSpot in September 2018 as a linguistic team manager. JIRA was already used by many teams in the company. Our localization team was already familiar with this tool, and my colleagues already went through a couple of JIRA implementations that were mostly focused at issue tracking and establishing critical production communication with our many internal stakeholders.

Towards the end of 2018, we were facing even more complex requests with increasing volumes. The need to revamp our JIRA implementation was becoming more and more apparent.

The main challenges that we were facing were the following:

1) Our workflows in JIRA were using only statuses and not taking advantage of transitions.
2) We had a lot of custom fields that needed to be reorganized, discontinued, and set properly, especially to avoid typos or invalid data.
3) We were not creating an environment that made it easy to extract important KPIs like word count, financials, project duration, and so on.

It’s important to have a solid workflow in JIRA that is supported by reality-checked transitions. According to Atlassian support documentation, “A status represents the state of an issue at a specific point in your workflow. When defining a status, you can optionally specify properties. A transition is a link between two statuses that enables an issue to move from one status to another. In order for an issue to move between two statuses, a transition must exist. A transition is a one-way link, so if an issue needs to move back and forth between two statuses, two transitions need to be created.”

Transitions enable automation in JIRA, like automated sub-tasks creation that takes into consideration data and parameters in the parent tasks; error messages that mitigate risk of mistakes; and customized notifications triggered by events or data to specific email aliases.

We had to further customize our JIRA implementation and the following process was the outcome:

1) Form: this constitutes the access point for our internal stakeholders.
2) Task/request creation: using the information in the form, a Task is created.
3) Scoping: one of our localization project managers will analyze the request and initiate Scoping.
4) Data in: while working in the JIRA Task and Sub-Tasks (at languages level), our team will update critical information like target languages, costs, word count, due dates, instructions, and documentation.
5) Data out: we constantly pull data out of JIRA and maintain dashboards that show budget spent vs. quarterly allocations, word count, average project duration, content types progress, and so on. Using JIRA custom fields, we also trigger workflows in other essential tools for localization pipelines.
6) Execution: the team members can independently execute their work knowing what to do while interacting directly with internal key stakeholders.
7) Iterations: we work in a fast-paced and change-driven environment. JIRA makes it easier to manage iterations.
8) Delivery: this is the final step, and we take advantage of Jira comments and notifications to notify requesters and stakeholders.

In two years, we have gone through two major upgrades of our JIRA implementation. The outcome has been that this powerful work management tool has become our source of truth when it comes to localization KPIs and transparent, readily-available progress tracking. This has been essential to facilitate the management of a multimillion-dollar annual localization budget and word count volumes of millions per quarter.

In my experience, the time and effort invested in data entry via JIRA or similar tools has always been worth it, especially when managing remote teams. This often small-time investment leads to a multiplier effect of positive outcomes, especially for those who are actually executing the tasks.

If you are curious to know from where the name “JIRA” comes from, I suggest visiting support.atlassian.com and searching for “What does JIRA mean?” It is quite a funny story that involves a very famous Japanese oversized monster.