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
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.
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!
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would suggest splitting the development cycle and release cycles.
Development cycle:
Release cycle:
As a result, you can
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.