Prioritize and reduce technical debt in your Jira backlog with Compass

đź’ˇ Executive Summary

Tech debt, caused by scale and the necessity to quickly ship new features, is a common challenge for software teams. Teams take on tech debt ship quickly, but too much leads to decreased velocity in the long term. Atlassian Compass, an internal developer platform (IDP), gives teams a centralized software catalog so developers can find information faster and understand the health and performance of their software. By linking Jira issues to your catalog and health measures in Compass, teams can identify and reduce high-impact tech debt when prioritizing their backlog while shipping new features with consistent speed.


 

Tech debt in your backlog out of control? You’re not alone

Technical debt is outstanding work promised but not delivered to the customer, defects in the code, or work items that hurt agility.

Dan Radigan, Atlassian

Build, measure, learn - fast. Agile software teams ship code with incredible speed. The tradeoff is technical debt, an unavoidable phenomenon that increases code fragility and slows teams down. How well does your team understand its technical debt? What insights inform how to prioritize your backlog to reduce technical debt while continuing to deliver innovative new features? Read on and learn how to assess Jira backlog priority and tackle your team’s technical debt for faster software delivery.

 

The root cause of tech debt: speed and scale

Teams are under constant pressure to deliver new features quickly. At the same time, as products and teams grow, complexity increases and organizations experience a proliferation of services and software sprawl. Ownership becomes unclear, knowledge silos form, and finding information becomes a greater challenge. As product complexity grows, codebases become larger, and teams continue to prioritize shipping new features, the likelihood of bugs and performance issues increases. The stats are staggering:

 77%

15%

70%

of devs say their codebase grew 5x over the past 3 years 1 percent of a dev’s day that’s actually spent coding 2 of devs encounter a knowledge silo at least once a week 3

Companies have to move fast to remain competitive, and successful companies will grow in size, revenue, and breadth of products, so virtually every organization must learn to manage technical debt effectively. How well does your team comprehend its technical debt?

 

Prioritize your backlog and reduce technical debt with Compass

At Atlassian, we use Compass to maintain a centralized catalog of all services, libraries, APIs, and other software components built and operated by our teams. With Compass, teams use the software catalog to easily track service ownership, connect data from across the organization, and reveal the health of our software. These insights empower teams to effectively prioritize their work, move fast, and maintain a high code quality bar. Using these insights to address the right tech debt now leads to higher velocity in the future.

In this article, we’ll show how Atlassian uses Compass, our developer experience platform, to reduce technical debt and prioritize our Jira backlog.

 

Compass helps teams understand the impact of their work and plan effectively

Compass is Atlassian’s developer experience platform, also commonly known as an internal developer platform or IDP. Compass was created to aid Atlassian’s microservice journey and streamline our developer experience. Compass reduces day-to-day friction for developers by helping them find information and insights faster, and speeding paths to production:

 

catalog.png health.png extensibility.png templates.png

Catalog

Reduce cognitive load with a comprehensive software component catalog

Health

Apply health scorecards, build and communicate policies, and improve your developer experience

Extensibility

Connect critical service details to save time searching and reduce context switching

Templates

Automate consistency and accelerate paths to production with pre-built software templates

Compass components give teams a centralized way to catalog and understand their software. Components are anything that lives in a repo - a service, library, ML model, etc. You can natively link these in Jira so that issues in your backlog connect to the real pieces of software they impact. This helps teams understand the impact of their work and how it relates to the big picture of their software.

Atlassian’s platform engineering team relies on Compass to centralize information, standards, and practices that help us maintain a good developer experience and engineering culture. That means autonomous teams, clear standards and practices, clear service ownership, and less time searching.

 

Get up and running with Compass in minutes: Setup your catalog, metrics, and scorecards to get started

You can get started with Compass in minutes by following a few simple steps: (1) import your components, (2) assign Teams to own your components, (3) configure scorecards.

 

Step 1: Import your components from wherever they live today.

For most teams, that means connecting a Source Code Management (SCM) tool, like Github or Bitbucket, or importing repos linked to your Jira projects. You can also import components from a CSV file or any combination of these methods to quickly build a comprehensive catalog of everything your developers build and maintain.

You can get started with Compass in minutes by importing your components from wherever they live today. For most teams, that means connecting a Source Code Management (SCM) tool, like Github or Bitbucket, or importing repos linked to your Jira projects. You can also import components from a CSV file or any combination of these methods to quickly build a comprehensive catalog of everything your developers build and maintain.

fig1b.gif

 

Step 2: Assign Teams as owners of your components

Generally, each component should have one Team assigned that’s primarily responsible for its operation. Adding an owner Team to each component reinforces a culture of autonomy, helps developers stay on top of relevant information, and expert coverage of each component even if an individual or lead is unavailable. Compass uses Atlassian Directory for Team definitions, so any existing teams you’re using in Jira are already available.

With the component catalog, developers across your organization can quickly find documentation or recent CI/CD activity associated with any service or library. This boosts developer productivity by reducing time spent searching for information and eliminating interruptions for information that can now be self-serviced.

When an SCM is connected, Compass automatically detects events like deployments and aggregates them in the Activity Feed. Based on the events from your repo, Compass automatically calculates several key metrics out of the box, like deployment frequency and build success rate. You can set up DORA metrics and even track custom data, like the number of security vulnerabilities outstanding for a given component.

fig2.png

 

Step 3: Configure scorecards to apply standards to your components

With your catalog populated and metrics flowing in, it’s time to start using scorecards. Scorecards are used to build standards and apply them to components across your organization. Scorecards can use any desired targets for component metrics and field data. This helps you ensure your software components are healthy and teams are following the recommended practices. Compass comes with a few default scorecards out of the box with metrics we recommend you track, such as Component Readiness and DevOps Health, and you can create your own custom scorecards. When you see what scorecards are failing for your components, you know what technical debt you need to address!

fig3.png

To continue with the example above, let’s tackle security with a custom scorecard that will fail if there is more than one open security vulnerability at a given time. Security vulnerabilities are a classic example of tech debt. First, create a metric to track Security Vulnerabilities and configure it to pull from the correct source on your various components.

Next, go to the Scorecards tab under “Health” in the top navigation bar. Click “Create Scorecard,” fill out the details, and make sure to add the Security Vulnerabilities metric you just created as the scorecard criterion. Let’s say the scorecard will fail if there is ever more than one security vulnerability open at a given time. This is a good choice for Tier 1 services that are critical to the operational state of your software. Set the operator to “less than or equal to” and the value as one. Set the weight to 100%, click Create, and now you have a centralized way to track security-related risks and give teams clear actions to improve the health of their software.

In practice, you’ll configure multiple scorecards to measure a variety of standards to get a comprehensive view of your technical debt.

 

 

Link Compass to Jira: Identify high-impact tech debt and prioritize your backlog

Now Compass is configured, we have everything we need to begin identifying and tackling tech debt. First, make sure your Jira project is opted into Compass components by clicking “Components” in the left-hand navigation bar, and checking the drop-down field on the top right. If you’ve opted in, it should say “Compass components.”

Next, go back into Compass and examine your scorecards. Identify areas where scorecards are either at risk or are already failing, and based on your team’s priorities, determine the most important problem to solve. You can view a specific scorecard from the “Health” UI, and see how all applicable components measure up. You can filter further by owner team to understand exactly how your own components are scoring and identify the technical debt that requires your attention.

fig3.png

Let’s consider another example using the DevOps Health built-in scorecard. You are reviewing your team’s components and you notice that several are failing the Deployment Frequency criterion. The scorecard is defined so that if there are fewer than five deployments per week, you notice that some of your components only have one or two deployments per week. This is a potential issue that needs investigation. Perhaps there is a problem in the build process or deployment pipelines, or maybe your team is struggling with the technical difficulty of their task. Either way, it’s technical debt that is worth addressing.

Return to your backlog and see if there are existing issues that address this problem of slow deployments. If not, you can create a new issue directly from the Scorecard page in Compass. Make sure those issues have the correct Compass components tagged on them so you can stay organized and directly track the impact of your backlog.

fig4.png

From there, you can confidently incorporate those issues into your next sprint or add them to your Kanban board. You know these issues are high-priority technical debt, and you know that the work you’ve done will impact your software architecture’s performance. After your team resolves the issue, you can go back to your DevOps Health scorecard and see the history of how you improved deployment frequency over time. This is a great visual to show leadership and to show your team as you discuss the value of your work.

fig5.png

 

Recap: Use Compass to prioritize your Jira backlog and reduce technical debt

Technical debt is inevitable in modern software delivery, but effective teams know how to prioritize high-impact technical debt to maintain a high level of reliability while shipping innovative new features with consistent velocity. Linking your Jira issues to a centralized Component catalog in Compass gives teams insights on work impact and allows them to make effective tradeoffs between tech debt and feature delivery with just a few steps:

  1. Quickly setup your software catalog in Compass by connecting your SCM, importing repos from Jira, or importing them from a CSV file

  2. Start with built-in scorecards, then build your own with metrics and other data sources to track software performance against your organization’s standards and practices and identify high-priority tech debt

  3. Make Compass part of your weekly rituals as you move tech debt from “Backlog” to “Done”, preventing incidents while consistently delivering new features

 

Get started with Compass for free.

 

2 comments

Tarang June 17, 2024

Interesting that Compass sees Team as the conical for ownership, which doesn't appear to be the case for issues in Jira.

Aside this, my experience has been that most teams or groups haven't explicitly defined what they mean by Technical Debt, and even when they have defined this most teams don't actually keep a registry to track this. So it is a tough problem to address and so not sure is more tooling the real answer. 

So I see keeping a meta view with score cards for code health can help narrow down the need to address what may be rising cost of technical debt and sure keeping a component registry will help in a well governed system where components are well defined yet see this to be challenging in an eco-system of many products and product teams.

Like • Anthony C likes this
John S Davidson June 28, 2024

I also was looking at a slightly different definition of Tech Debt than found in this article.

In particular this quote:

"Technical debt is outstanding work promised but not delivered to the customer, defects in the code, or work items that hurt agility."

Dan Radigan, Atlassian

 

However, to ensure I was looking at it correctly, I looked up Atlassian's definition:

https://www.atlassian.com/agile/software-development/technical-debt 

Which includes:

"Technical debt is the difference between what was promised and what was actually delivered.

This includes any technical shortcuts made to meet delivery deadlines!"

 

Re-reading the Dan Radigan quote in the context of the above made it ring more true.

From there Compass looks like it will record it for you, which is a big plus.  Sounds like (and I haven't played on Compass) it shouldn't really matter what your definition is (within reason!).  How I read it is that assuming the "team" is looking at the Compass scorecards rather than an external party (management or reporting group) so as long as the team has a definition, the scorecard can be configured to report on it.  If there are external parties looking at the scorecards then an agreed term across Dev teams is required, but that can start out basic and grow as required.  It looks like it doesn't matter whether a different team owns a component, and may define tech debt differently, because you're reporting on its impact to your own product.

 

It will be very much (as all things are) a case of "only as good as the data you input".  i.e. if your component catalog is poor, and component ownership is poorly recorded...

 

I wasn't sure how Velocity is reduced by Tech Debt.  Even tickets covering Tech Debt will have Story Points associated and as such would contribute towards the Sprint Velocity average.  Velocity towards "new" features would be lower, but is that even a metric available currently?

 

For a Scrum Master or Product Owner I think Compass will be a great addition to Scrum Planning/Backlog Prioritisation.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events