nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Release Management Workflow & Several Statuses categorized as "Done" Best Practices

Robert Campbell_md7mql

Context

I am a Jira product manager/administrator and work within an enterprise organization that is working towards agile; however, they have a long way to go. Utilizing the workflow example below, teams get to the point of "In UAT" and technically speaking their work is done. Within our organization, teams are dependent upon other teams responsible for change & release management. Unfortunatley, there is no such thing as incremental releases here and therefore; the next release may not be executed for a few months.

Scenario

Let's assume we have a scrum team that has the average 2 week sprint while taking into account what I mentioned above. When a team closes their sprint, all issues are considered not "Done" and as such, move to the next sprint. This is obviously bad for many reasons.

Question

What is the best way to handle this situation with respect to workflow configuration?

Thoughts

Statuses

Once upon a time I felt that there should only be a single "Done" status; however, I've recently turned a new leaf. For example, even the out of box bug workflow includes both the "Resolved" and "Closed" statuses. (Yes, I understand why that is and quite like it).

Based on my Jira knowledge and research I believe the first issue that needs to be addressed below is that the "Awaiting Release" and "Released to Production" statuses should be categorized as "Done", e.g. green. Or should I? The other half of me shouts there is only one "Done" and it's either "Done" or it's not.

Resolutions

Once a team completes "In UAT" they click the "Ready for Release" transition button or drag it via the board. As a reminder, this is what many teams here define as "Done" due to various silos that exist here. In order for their reports to reflect accurately, I would need to apply a resolution via post function or perhaps a resolution screen to the "Ready for Release" transition between "In UAT" and "Awaiting Release". This goes against my grain as I have always been a firm believer that resolutions should only be applied at the final status or "Done". Also, as you all know, within a board, all statuses categorized as "Done" should be placed within the final column; however, in order for what I mentioned to work (as far as I can tell thus far) I would have to create individual columns in the board for each "Done" status effectively making "Awaiting Release" and "Released to Production" green statuses in a yellow "In Progress" state.

Possible Solutions

Trash this workflow and everything that looks remotely like it and replace with a workflow that is configured to reflect how many team's here define "Done". This would mean transitioning from "In UAT" straight to "Closed".
Change "Awaiting Release" and "Released to Production" to the category "Done" (green). Then apply a resolution to the transition between "In UAT" and "Awaiting Release". Then configure their boards to where the final three "Done" statuses each had their own column thereby giving the ability to drag and drop an issue from "Awaiting Release" to "Released to Production" and finally to "Closed". Naturally, the movement of the issues to "Released to Production" and subsequently "Closed" would not occur until sometime later when the release actually takes place. Of course they could also just take care of those final transitions in bulk when appropriate.

The 1st option would work; however, is it truly representative of the cradle to grave SDLC process? Not really. That said, given the silos that exist here perhaps this is the best solution.

The second option more accurately represents the lifecycle of an issue; however, what bothers me is the way in which I believe the teams would have to configure their boards. Not to mention the placement of a resolution prior to the truly "Done" status.

What a debacle.

Closing Remarks

You can consider me the Highlander of Jira within this global enterprise organization. I quite literally have zero support staff at this point and serve as the governance board, Jira SysAdm, Jira Adm, Customer Support, etc. for four-thousand users and climbing.

I cannot express enough how badly I need my fellow Jira guru's to chime in on this one and share some best practices, recommendations, etc.

Your help is appreciated more than you know; thank you in advance Atlassian community. I anxiously await your input.

SDLC Workflow.PNG

Accepted answers

John Funk

Hey Robert,

I feel your pain. :-)

Personally, I would consider the work to be Done when it hits the Awaiting Release status. In fact, I would just rename that to Done itself.

But I would group the issues by Release, ie. populate the Fixed versions field with the release you created. Then when you actually release the code, then do a Release on your board.

I would even create a Swimlane for issues that where Done and have a value in the Fixed versions field and place it at the bottom of your Swimlanes so those tickets don't clutter up the board.

That's my two cents. :-)

I would further encourage you to move more towards Kanban versus Scrum, but I am little biased there, too.

Good luck with it all!

All comments

John Funk

Hey Robert,

I feel your pain. :-)

Personally, I would consider the work to be Done when it hits the Awaiting Release status. In fact, I would just rename that to Done itself.

But I would group the issues by Release, ie. populate the Fixed versions field with the release you created. Then when you actually release the code, then do a Release on your board.

I would even create a Swimlane for issues that where Done and have a value in the Fixed versions field and place it at the bottom of your Swimlanes so those tickets don't clutter up the board.

That's my two cents. :-)

I would further encourage you to move more towards Kanban versus Scrum, but I am little biased there, too.

Good luck with it all!

Robert Campbell_md7mql

Thank you for the reply John. I've actually already created a few workflows that vary on how a team may define "Done" and it looks like this is going to be the way to go until they can break down some silos here. Did I mention they had over a 100 workflows when I first started here and over 400 custom fields? Workflows with no resolutions, statuses based on tense, e.g. Deploy, Deploying, Deployed. SMH

Thank you for taking the time to reply.

John Funk

@Robert Campbell - understand that, too! We have about 70 workflows and well over 100 issue types that we are transitioning to about 10 workflows and the same number of issue types. We have lots of custom fields, too - and I know everyone says they are bad, but if they are helpful to the team, then I am okay adding them. Our basic premise is that if you are not reporting on the field (looking at the actual values at least weekly, if not daily) then there is no reason for the custom field.

Sounds like you are on the right path if you can get the cooperation.

unknown

I agree with John's observations and would caution on becoming overly complicated. It is also important that your teams work from a strong Definition of Done that they agree on, if they don't have one already.

Yuri Kudin _Release Management_

I would suggest splitting the development cycle and release cycles.

Development cycle:

Let the teams define own development workflow and the way they are working in order to achieve DoD on a story level, without taking into consideration the release part.
Ask the teams to use versions (fixVersion field) for all issues. As is was designed in Jira. Or plan the versions upfront

Release cycle:

Extend Jira version workflow with one of the add ons for release management (for instance this one) in order to visualize the steps to meet DoD on version level. E.g. Integration testing, UAT etc
Separately track release workflow. (for instance, in B2B organizations the product team can start new version development while rollout team will be working on releases for a number of clients)
Implement change management process (if needed, of course )

As a result, you can

Split development and release responsibility. In enterprises rollout is separated from development
Avoid over-complication of development workflows
Build a release management process which will be working with any dev process (Waterfall, Scrum, Kanban, XP etc)
Be flexible in both (development and release) process adjustments as the coupling is creating unnecessary dependencies

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server

kanban

scrum

workflow

status

release

done

resolution