Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Using Atlas for Release Tracking

We are interested in using Atlas for release tracking, since it seems to offer obvious benefits for keeping the business appraised without having them get lost within Jira.  I wanted to get some Atlassian & peer feedback to see if this is a valid use of Atlas & how we might improve.

Before using Atlas, we relied on the Jira Releases page to show which versions were in-flight, along with their anticipated release date. This was problematic because:

  • We had to extend Jira access to individuals who don't normally use Jira. Think field teams who aren't engineers & need to sift thru the noise.
  • The information was prone to misinterpretation. A status of "Done" in Jira means something specific to engineers (QA complete, but not not yet GA), but to outsiders they interpreted it as "it's complete".
  • Changes aren't automatically communicated. If we shifted the Jira Release's date, stakeholders would not know without a separate manual effort to notify them. And history was lost, so there would be accusations of dates slipping at the last minute vs. we've been discussing it for quite awhile.

It seemed Atlas would help address much of the above, while adding other benefits (status emails, Slack updates, etc.) that could relieve our communication burden.

We originally modeled it as 1 Project per monthly release, each tagged with #release. For communicating included features, we experimented with both bulleted lists of Jira epics (in the About tab) or linking separate child Projects per Epic.


  • Weekly update cadence was beneficial. Encouraged us to keep the information fresh, and Monday summarizations set the tone for each week.
  • The #release topic embeds well within Confluence. Clearly shows dates, status, and the most-recent updates.


  • The About tab questions aren't applicable to projects. The What & Why apply more to the individual features being shipped vs. the release itself.
  • Understanding the release's content was painful. For both maintainers & consumers. Maintaining a bulleted list of Epics was tedious, and seeing which child Projects are linked is not easily-understood. Also because the linked Projects are listed in the sidecar, longer names get cut-off.
  • Difficult to focus on at-risk features. Jira links communicate Jira statuses, which aren't clear if work is in jeopardy of not making the release. 

To address the Project-related drawbacks, we are modeling one of our releases as a Goal, also tagged with #release:


  • The About tab is simple. The perfect amount of information, without having to hijack an inappropriate field ("Why", etc.) to share context.
  • Goal rollup is helpful. We have a team goal of releasing at least once per month, which we modeled as a goal. Releases modeled as Goals can be sub-goals of that parent goal, allowing for clear tracking of our commitment.
  • Display of linked child projects is great. From a Goal page, I can see a simple, clean list of the child Projects (listed as Contributing Projects under the About tab) without having to dig thru a crowded sidebar
  • It's easy to focus on at-risk features. Because the Contributing Projects section also buckets Projects by status (off-track, at-risk, etc.), we can easily prioritize greater focus on keeing individual features on-track.
  • Goal icon color dynamically represents goal status. On-track = green, pending = grey, etc.


  • Monthly update cadence is too infrequent. We release once per month, so we couldn't take advantage of any built-in workflows (nags for updates, status emails, etc.)
  • The #release topic embed does not include goals. So we lose several benefits, including seeing date & latest update. 
  • Embedding a Goals search page result lacks the same information. I've submitted a feature request to have the same information included for Goals that Project embeds also include. But until then, embeds are totally useless.

So based on the above, I'm curious if others have attempted to use Atlas for release tracking — and if you have, what have you found that provides benefits without piling on too many drawbacks.

0 answers

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events