Release Status

[Jason Hollis]

This question seems to be poorly answered or understood across the inter-web so here goes.

Problem: Jira release STATUS is hard coded (so it seems); essentially a release is RELEASED or UNRELEASED.

As a Product Manager I need to convey 'where we are at ' to a variety of stakeholders. Unfortunately the 2 options above don't answer that question.... it's just too finite. 

Now I could say to stakeholders 'just dive into Jira and look at the release - it clearly shows the progress of any release'. The problem with this.. "what's Jira" is the sales teams response, and rightly so.

Integrating with a tool like Aha doesn't help either, as the mapping options in Aha are extensive and completely customisable, however there is not a lot of agility on the Jira side as unreleased / released are the only status triggers. 

Keen for any help to assist advising stakeholders where a release is at, preferably without them logging into Jira. 

[Linda Rasmussen]

I have the same question.  We have created a custom field "Target Release" (Version Picker) to let the developers know what Branch to start working on the item in.  The actual releases go out with a Field Revision at the end.  So in the Releases section we want the status of the Target Releases to be "Starting Branch"

[Nic Brough -Adaptavist-]

I think you're struggling for an answer because part of the question is not defined, and you can't get an answer to an undefined question.

You need to define "progress" in full, then you'll be able to get a clear answer. 

For example, are you looking at the number of issues from a fixed plan that have been released?  Or moved to "done" or "closed", or just passed testing?  Or are you looking at the volume of estimate vs work done?  How are you handling new things coming in?

[Jason Hollis]

In a nutshell Nic like many other posts I have seen, all I need is Jira flexibility to have more status options for a release. That is, I don't want this dictated by Jira hence the full scope of my requirements are irrelevant. Yes it may include 'In Progress' for sure, however it may include anything our team decides makes more sense to our stakeholders. 

[Nic Brough -Adaptavist-]

I understand that, but you still need to define what you are trying to measure.  "Status options for a release" doesn't really explain anything about what you're trying to do, let alone how you're seeing "progress" on it.

[Jason Hollis]

I am really sorry Nic however this seemed like a really simple question, at least to me, and your responses are not really assisting me and are in fact a little derogatory in my opinion. Let's just call this a day and I'll move on to trying to come up with a solution on my own. 

[Nic Brough -Adaptavist-]

I don't mean them to be derogatory.  

I am trying to understand what you are trying to report on, but I am frustrated by you not answering the questions I've asked in a meaningful way.  My instinct is that you are not actually sure on what you are trying to report on either, which makes it impossible to form a decent answer.

[Matthieu B.]

@Nic Brough -Adaptavist- I have a related question that could well match what @Jason Hollis was trying to achieve (let us know if you found another solution since last year...)

I would say from my angle (as a Scrum Master in SaaS) "Released" is a very incomplete status information for most stakeholders. As the obvious next question is Released where?

Our Scrum Teams tend to "Release" regularly from their local machine to Dev through the Sprint and before testing, the work is considered Done, after testing passed once that work has been released to Staging. But those that really care about the status of a release want to know when it's on UAT and Production (not even mentioning wether it is inactive on Prod or activated)

We are on Jira Cloud and already have Portfolio and Scriptrunner for Jira Cloud. Ideally I'd want to avoid having to purchase and manage another plugin, so what's the best Jira native way or managing this if we can't customise release statuses?

[Matthieu B.]

Thanks @Jason Hollis for your feedback after a year! Aha.io seems neat indeed, but we are already using portfolio with initiatives, and our Product Owners have their own boards etc. so I doubt I can convince anyone very soon to migrate to Aha.

But your reply indeed gave me further food for thoughts, and confirmed some other work around we are also using a bit like you describe. We have a Jira Project setup purely for managing the releases. Each releases basically move through a Jira board (Trello style) as a Jira ticket itself. Tickets that need to be released are linked to these release tickets.

In fairness to Nic, what we are trying to achieve can indeed be resolved in many different ways. As an external party to this conversation I believe he was trying to get to the root of the problem to try and provide the best solution, but I won't insist on that wound :)

With all the great work that when into Jira and Bitbucket, and their integration I just wished there was an easy native way to see releases move from one environment to the next, and/or to clearly see which version is aimed for which environment. It seems quite a gap in the Atlassian suite of tools, and one that looks like could be fixed with minimum efforts...

[Nic Brough -Adaptavist-]

Jason, you are right in saying I'm not grasping what is being asked, but this is because you refuse to answer the questions I've asked to help me to understand what you want.

Matthieu, your comment does give me something to work with, and I agree that there appears to be a hole in Atlassian's stuff in knowing "what release is where".  That is actually covered in Bamboo though, where they expect you to compile/build and deploy releases, pushing them into systems automatically (And most of us that do that push the information about releases back into Jira, often by having Bamboo update all the issues in the release).  There's pages in Bamboo dedicated to giving us a "what release is deployed where" view.

[Matthieu B.]

Thanks @Nic Brough -Adaptavist-.  Beyond the fact that most Jira/Bitbucket users would still be using Jenkins (instead of a very costly migration to Bamboo) I'm not even sure what Bamboo would update in Jira.

Would you have some articles or screenshot to point to?

I believe Bamboo would be using the same WebHooks/Triggers that Jenkins would use? How would you expect Bamboo to update Jira? Would it be changing the status of an issue past "Done"? e.g. you'd have extra statues after Done and that's what Bamboo would update?

Even if (extraordinarily) we would migrate to Bamboo, I wouldn't want non Development departments to have to go outside of Jira. So the question about the visibility of where is the released deployed still remains - and belongs inside Jira in my view (as the single source of truth for non tech departments)

[Nic Brough -Adaptavist-]

Annoyingly, I can't find the screenshots I used to use, but Bamboo has a concept of "Deployment plans" which take build artifacts and deploy them to wherever they may be needed as releasese.  The missing screenshot is of a report that tells you what environments that deployment plan has been applied to.

Bamboo feeds back into Jira directly in the build panels on issues - people using Jira don't have to leave it to kick off, monitor or even release builds, and it's tightly integrated with Bitbucket in a similar way.  You could get it to update status and other data, but most of the default data exchange is more about display than update.

https://confluence.atlassian.com/bamboo/understanding-deployment-releases-357335182.html

There's also a screen in the bamboo help which explains it better than I do.

[Matthieu B.]

Thanks @Nic Brough -Adaptavist- that's very helpful. I'm not sure if you could do something about the order of our latest comments, they appear quite randomly now in this thread (in between comments from August).

Would be helpful for other readers if there was a way to put them back in a chronological order...

[Matt Kepple]

The way we use is Releases is to track the status of a chunk of work that has been paid for by a particular client. Let's say we have four stages

- Proposal being created

- Proposal sent to client

- Proposal signed-off-by client

- Tasks assigned to sprints

Then in this scenario it would be helpful to be able to have these 4 statuses as additional Release statuses so that I could see the status of each release.

The reason that we don't use Epics for this is that we use Epics for issues that are on our roadmap rather than for bodies of work that are paid for by clients

[Jared Warren]

Anybody ever figure out a good solution to this that doesn't require an add-on? It seems like a major deficiency in the Release Hub.