Understanding JIRA Align

With over two decades of experience in digital media technology, and at the forefront of streaming driving launches for HBO GO and Cinemax GO both domestically and internationally,  John has overseen product management, program management, quality assurance, data analytics, strategic partners, and technical customer support for named brand global companies.  At Paramount Global he leads the PMO team setting best practices and standards in software product development, agile delivering, agile coaching, and training.  

If you work in software development following an agile development methodology, then likely you use Atlassian’s JIRA product or you have used it in the past.  JIRA allows teams to define their work in manageable chunks, planned either on a Sprint basis or a Kanban-style board to visualize the flow of work.  JIRA is focused typically at the team level, with a view to a few increments of work.

Why JIRA Align?

Where JIRA itself begins to hit limitations is from a team of teams perspective.  Scaling agile across the enterprise to many or hundreds of teams is not something you can easily plan and visualize within JIRA.  If you are working within a product development organization on a consumer product with wide adoption with regards to a number of users and wide adoption globally, then likely you are operating in a team of teams scenario.  To address this need, JIRA Align (JA) has been introduced.

JIRA Align Capabilities

JIRA Align is intended to connect business strategy to customer outcomes at scale.  It can capture strategy and tie it to execution through OKRs.  There are a slew of features focused on long-term planning, road mapping, risk, issue, and dependency management. 

​"JIRA Align is intended to connect business strategy to customer outcomes at scale.  It can capture strategy and tie it to execution through OKRs.  There are a slew of features focused on long-term planning, road mapping, risk, issue, and dependency management.  "

Data is synchronized between JIRA and JA, based on your designation of specific projects and boards.  JA extends JIRA to manage program, portfolio, and enterprise level planning activities.  The tool is designed specifically to support teams following SAFe (Scaled Agile) methodologies, although capabilities are still valuable to teams following other methodologies.

Dependency, Issue, and  Risk Management

Dependencies between teams and/or programs, both internally as well as externally (e.g. partners, vendors) are typical in the enterprise.  JA has a few different views to visualize dependencies and track details.  

You can track the owner, time frame for delivery (committed Sprint and Quarter), and current tracking status.  This allows teams to stay on top of dependencies and manage any associated risk.  JA takes the SAFe ROAM-based approach to risk management by designating risks as resolved, owned, accepted, or mitigated.

Long Term Planning

From a long-term planning perspective, JA allows you to plan multiple quarters out.  You achieve this by leveraging their Roadmapping tool and the Program Board.  The latter is intended to represent the agreed-upon plan between product management and development teams for the current Program Increment (PI) (aka Quarter).  The Program Board visualizes  the status of features, dependencies, objectives, and milestones by using different symbols and color-coding.  You can see the different Agile teams, what they plan to deliver, and when.  Issues, blockers, canceled, and orphaned items are color coded to easily identify items needing attention.

For those organizations conducting quarterly planning in a team of teams setting, and those specifically conducting PI Planning, JA has a Program Room concept.  This is intended to facilitate long-term planning activities.  For instance, you can see the teams involved in delivery for the quarter, defined objectives, team load and velocity, risks, planned work on a Sprint by Sprint basis, as well as progress.

Things to Know Upfront Before Implementing JIRA Align

Implementation of the tool is no small feet.  This is largely due to changes needed with your existing JIRA instances:  both configuration and process - new ways of working are necessary to “align” with JIRA Align terminology and structure.  To assist Atlassian offers multiple packages from a professional services perspective to get you up and running, as well as a strong and broad partner network.  It is highly recommended to purchase PS, as the learning curve is steep.  There are many decisions you need to make and there are potentially multiple ways to implement.

From an issue-type hierarchy standpoint, out of the box, JIRA Align and JIRA, use different hierarchies and terminology.  This is likely because JIRA Align is based on SAFe, while JIRA is not.  The good news is you have options here to hide certain issue types or rename them.  The ability to hide and/or rename exists through the product.  I find this very useful for Objectives and Key Results (OKRs) for instance.  Also, remember that data synchronizes bi-directly between JA and JIRA.  So from a hierarchy standpoint, features in JA are intended to synchronize with EPICs in JIRA.  JIRA also has a Feature Issue type though.  Therefore this is confusing to product and development teams.  One such approach is to rename the issue types so that it's clear what is synchronizing in both systems.

There is likely another change you will need to make concerning your JIRA “Programs” and JIRA ``Projects.”  JIRA Align has many models for structuring projects in JIRA to synchronize with JA.  The approach I believe is the most common and recommended is to create a new JIRA Project to represent your Program, and ensure that each Agile team within that Program has its own separate JIRA Project.  So for teams that were working out of a single JIRA backlog to manage development items under a single Program, you’ll need to split them into separate Projects.

Another change of note is with regards to workflow schemes in JIRA.  Workflow status along with progress against stories (points closed out or stories accepted) has an impact on Status and Progress within JA.  JA will in many cases dynamically calculate progress and status, based on the hierarchy of issue types, and estimation of the work delivered and accepted.  For this to work you will need to use the JA workflow mapping tool, to map your Workflow states in JIRA to the JA workflow state.

A big piece of the learning curve with JA is that it is completely different from JIRA, and there are many features packed into the product.  Therefore navigating the UI is complex.  There are many places to drill down for further details so it is easy to get lost and know where to go to find information.  With that said, it's a powerful tool that can extend your ability for managing product development in a team of teams setting at an enterprise scale.