Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

×
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

Jira Change Management

** As a disclaimer, I'm aware that Jira Service Management does include a change management template, but we do not have Jira Service Management.

I'm curious if anyone out there in Jira Admin world has developed a solution for change management in Jira software? I have a user base of about 250 and often receive requests for customization or configuration changes to our Jira instance. These requests could be for global changes or project level changes. Regardless, it is a very manual process for me to track down anyone that could potentially be affected by these changes and make sure they understand and approve.

I have a 'Jira Admin' project that contains a 'Jira Request' issue type. Currently, the workflow is very simple for the Jira Requests (To Do, In Progress, Pending, Done), but I was considering adding approval steps to this workflow. The idea is to have new requests go through some type of approval before it even falls on my board for actions to be taken. The problem that I'm having a difficult time solving is that we need approvals from at least one development lead, one solution architect, and one business analyst supervisor. This would be easy enough to solution through the workflow by adding an 'Approved' status if we just needed a single approval, but we are wanting to make sure all teams are aware of possible changes.

 

6 answers

1 accepted

Suggest an answer

Log in or Sign up to answer
1 vote
Answer accepted
Paul O
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Aug 02, 2021

Yes, JSM should be your first choice but it’s perfectly possible to build out something functionally similar in Jira - especially if you have access to Automation and/or add ons like JMWE.

For approvals, you can use a hidden field as a counter and increment the value each time an approval is received. Once the value equals the correct number you can use automation to transition the ticket to an approved status (or simply add a condition to the transition so that it requires noApprovals = 3, for example).

To increment the counter you can either check approval comments and use groups to ensure that comments are coming from the right stakeholders or use a circular transition to create an approval action that is only visible to appropriate individuals and increments the counter on each approval 

@Paul O Thank you for taking the time to respond. This is useful information and helped me get closer to a solution. 

1 vote
Jennifer Choban
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Aug 02, 2021

@Jennifer Choban Thank you for taking the time to respond and providing the link.

Like Jennifer Choban likes this
0 votes
Josh Costella
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Aug 04, 2021

Hi Coby,

It seems like all of the responses have gone the functionality route. Creating the functionality for approvals in Jira is relatively straightforward so I'm going to avoid duplicating efforts here. What I would like to focus on is on your process as that seems like the actual problem needing to be solved. I'm going to pose several questions because I want to better understand your process and see what I can do to help! I promise this is not me saying you are doing anything wrong, but I can't help but try to help when I see a process that can be improved.

I have a user base of about 250 and often receive requests for customization or configuration changes to our Jira instance. These requests could be for global changes or project level changes. Regardless, it is a very manual process for me to track down anyone that could potentially be affected by these changes and make sure they understand and approve.

The first question I would ask is do you have any process restrictions on who can request changes to Jira? It doesn't sound like there are any if you have to then follow a manual process to track down stakeholders to inform and gain approval. I would consider adding one along the lines of only users who are managers and above can request changes to Jira functionality. That would reduce the need to contact people on behalf of requesters since you are funneling the changes via the stakeholders who need to "approve." If you can't change that, I would at least suggest requiring the requester of the changes to gain approval from all affected stakeholders before you begin work on the request. At least that would reduce overhead for you. 

The problem that I'm having a difficult time solving is that we need approvals from at least one development lead, one solution architect, and one business analyst supervisor. This would be easy enough to solution through the workflow by adding an 'Approved' status if we just needed a single approval, but we are wanting to make sure all teams are aware of possible changes.

Why does your process require so many approvals? What is your process around communicating changes? Do you think adding an approval process to the workflow will solve the problem of making all the teams aware of possible changes? Also, do all those teams need notified or does it depend on the change? How would you determine which change needed approvals? Do all of them or just ones that affect more than one team? If the changes affect more than one team, how would you account for that in the workflow since you have single approvals from each role? Are the roles providing approvals made up of people who are also atlassian admins? Do they have the necessary knowledge and experience to understand what they are approving? Are you empowered in your position as an Admin to say "no" to a requested change?

I ask all of these questions because, in my experience, the more the admin role can "own" what goes into the tools, the better. Gaining approvals from multiple sources is a last resort. I'm not saying you should make changes without telling everyone but you should feel comfortable enough and be empowered to question and analyze a change, its impact, and then make the call if a change should proceed. And then, and only then, should you seek approvals from stakeholders.

Approvals are going to be emails. Emails are unreliable. People reading and responding to emails are unreliable. Needing so many approvals is going to create a bottleneck and then you will have to deal with requestors being annoyed at how long their requests are taking to be completed. It will look bad on you even though it won't be your fault. If you need to gain approvals, I would consider adding approval notifications in multiple locations depending on what other communication tools you have. Ultimately, keep the process simple. Communicate only when you absolutely need to. Don't bother people unless you have to.

I had same problem as you and I created a new issue type Approval. It has three statuses - Open, Approved, Declined. I also added a manual trigger rule for Automation. It creates Approval issue and copies Description and Summary from original issue adding something like "Approval required". After issue creation it links it to original issue as Blocks.

 

Now every time anyone needs approval he/she selects the rule on the issue view page and triggers it. Immediately one can see a linked ticket and its status.

 

If you need three approvals from several persons - easy, just copy the rule two times and make different assigners. 

That's all.

I think you can tackle in a couple of ways (I'm not expert, so this is just my brain storming).

1. Use multiple steps in a workflow, Open -> Dev Lead Approve -> Solution Architect Approve -> Business Analyst Approve -> Ready -> In Progress -> Done. It would mean that one would need to approve before going to the next approver. 

2. Use automation where when a request is submitted and email is sent out to each team member or group that needs to approve. Then add additional automation to look for certain text and when it meets the criteria moves the workflow status. I have done some automation that looks for certain text such as "//Dev Approve//", and when there is a special text for each team then it will move to ready.  

As I said, just a couple of ideas.  

@Wendy McCurdy Thank you for taking the time to respond. I'm attempting a bit of a combination of your suggestion and @Paul O 

I created a jira project that I ask everyone in my Org for Engineering to enter a ticket, then we in the PMO review it before we implement.  Our Operations teams do the same for their part of the Org.   We have created our own workflows and approval process for these.  It seems the best options, for us, thus far, as you know, if you don't do something in this area, you will lost track of it all quickly.  We used to keep up with a confluence page where we tracked only major changes to workflows, that worked well, but it still didn't give us the volume of requests that come. This does.  

Because the Audit trail in Jira is pretty slim.

We also added in workflow steps where the button displays for the type of approver, and auto assigned to that approver.  This way once it is approved, jira shows who approved.

 

If for an alternate, we re-assign it, and then that person clicks to approve, and the audit trail shows who clicks on that action so we have an audit trail for that approver.

Like Coby Fuller likes this

@Karri Adkins Thank you for taking the time to respond and providing your teams solution.

TAGS
AUG Leaders

Atlassian Community Events