Using Atlas for Release Tracking

[Matthew McGarity]

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.

Benefits:

• 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.

Drawbacks:

• 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:

Benefits:

• 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.

Drawbacks:

• 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.

[tristan]

@Matthew McGarity Wonder a year on if you are still working this way?

We have just started trialing Atlas and one thought if you did want the weekly nudge is to add Sub-goals weekly, just as progress check in if you did not have sprints or milestones tied to them. 

Appreciate this would not line up as tidy as all on the same goal, but gives you some granular. 

[Matthew McGarity]

@tristan ATM, we're doing a hybrid based on our own internal workings:

• The consumers of such updates are more-limited than we originally-assumed: our leadership is less-concerned about specific dates & status than we thought, so the updates were most-important to the field teams (sales, CS, and solution engineering)
• Each of those teams tended to have one or more "champions" who were invested in following the weekly updates & disseminating them to their peers
• Each of those same teams also experienced typical turnover, some of which affected the "champions" — so some of our updates were not being watched.

While we continue to perform some updates in Atlas, we're now experimenting with using JPD to help communicate progress & expected delivery.  

[Dave Mathijs]

Interesting read @Matthew McGarity and although I like your attempts to use Atlas for Releases, it's my opinion that there are better - third-party - alternatives out there, especially if you want to keep the actual users up-to-date.

Looking forward though to feedback from other Community members to read their take on this interesting question/discussion.

[Matthew McGarity]

I agree there's a bit of square-peg / round-hole that occurs, although our current problems are more-driven by our current processes not following best practices vs. tool limitations.  The more our organization matures, we agree with your assessment.  I'm currently looking into JPD to see if it provides the visibility desired by the business while still shielding them from the chaos of Jira.