Traceability is dead; long live traceability
Photo by Hans-Peter Gauster on Unsplash

Traceability is dead; long live traceability

The top two things that Atlassian products do well are collaboration and traceability. Microsoft has already caught up on enabling collaboration natively within their products. Could traceability be the last frontier before Atlassian’s dominance in the collaboration market is challenged?

My first brush with traceability

Back in 1999, when I started my career as a software engineer developing telecommunication network products, I felt that traceability was one of the most interesting problems at work. Year-long development with massive project teams created a multitude of requirement specs, feature specs, code, builds, change requests, defects and defect fixes. It seemed like keeping traceability at the forefront was the surest way to have successful delivery using waterfall methods!

Why traceability is an interesting problem

A simple definition of traceability would be as the ability to understand and track changes throughout the software development lifecycle. In most organisations, that would mean right from requirements through to code, builds and deployments.

On a good delivery day when everything goes nice and easy, traceability can seem like a superfluous exercise. Many engineers or teams may not even consider this as a useful practice beyond regular code check-in comments. As an engineer, in all likelihood, the only time traceability would save your day is when you are racing against time investigating a critical problem. Especially when you are browsing through code developed over years by many people and trying to decipher why things are how they are.

However, as an agile organisation, traceability would be your super-ability to link together artifacts from all phases of delivery. It allows you to do quick decisions related to scope, quality, prioritisation and dependency. It also significantly enhances your ability to visualise how work is progressing across the value delivery chain.

Traceability using Jira

Atlassian's view of traceability centres around Jira as the source of truth for managing work within an organisation or a team. A picture is worth a thousand words - so let me put it all together in a single view.

No alt text provided for this image

Jira for stories, bugs and work breakdown

Atlassian simplifies the management of work-items by using Jira as a single system for managing different types of work-items like stories, bugs and tasks.

Epics are the simplest mechanism for breaking down work into features. Jira natively supports browsing across Epics and the issues in them.

Jira Portfolio or Advanced Roadmaps support hierarchical breakdown. Apart from the hierarchical view, browsing across the roadmaps/portfolio heirarchy is possible by adding the Parent Link field to the Jira issue view. This would allow going up and down the heirarchy without leaving the issue view.

The other mechanism that allows relating Jira items is issue linking. The standard issue link types are relates to / relates to, duplicates / is duplicated by, blocks / is blocked by and clones / is cloned by. However custom issue link types can be created by a Jira administrator. This is a very potent way to define and manage relationships between items in Jira.

Test artifacts

If you use a test-case management add-on such as Xray, even test artifacts like tests and test plans can be managed within Jira. Xray also makes it easier to link tests and test executions to defects found during testing.

Requirements

Confluence is a simple way to manage requirements, specifications and other knowledge artifacts. The simplest way to link a page from a connected Confluence installation to Jira is to paste into Confluence a link to the Jira item. This will display a link to the Confluence page from within the Jira item.

Code and CI/CD

Application Links or AppLinks, which provides the Confluence linking, also extends traceability to Stash/Bitbucket and Bamboo. For Stash/Bitbucket, this enables creation of branches, viewing commits as well as pull requests. With Bamboo you are able to see builds and deployments.

There are several add-ons that allow you to enable traceability to other source code management systems and CI/CD tools. This would allow code and build/deploy information on the development panel.

Extending traceability beyond technology teams

Using Jira to manage your OKRs will allow expanding traceability to strategy as well. Wouldn’t it be lovely to start browsing through your strategy pieces and see how they are shaping up in delivery. That’s a big assumption that the organisation has fully embraced Jira across the board!

There are also add-ons that integrate with several other collaboration and engineering/DevOps tools to provide one-way or even two-way traceability.

So how does Atlassian solve traceability?

Jira and add-ons allows you to manage most work-items within a single system with a unified approach to release management. Issue links helps to establish associations and relationships across various items in Jira. AppLinks and add-ons help create traceability to other artifacts like documentation, code and CI/CD pipelines.

The biggest game changer is the ability to browse through breakdown hierarchies or dependency structures without having to leave the browser tab. You could start with a Jira story and see everything associated with this story — be it requirements, code, builds and deployments —- nicely linked from here.

You could also browse up and down the breakdown hierarchy to help with decision making.

Atlassian has eliminated traceability being a problem that need to be solved. Instead traceability is here to stay as a capability that enables visual management and rapid decision-making within teams and organisations.

Originally published on bobtheagilist.com

To view or add a comment, sign in

More articles by Bejoy Jaison

Others also viewed

Explore content categories