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; } } }

How do you handle the conversation when leadership finally asks about Jira health?

James Bevan

Something I hear from teams managing Jira cloud environments is that governance work sits towards the bottom of the backlog until something forces it up.

A migration, an audit, a security review or a new tool being evaluated that suddenly requires clean data to work properly.

And when that moment does arrives, the team is expected to have answers. How many custom fields do we have? Which projects are actually active? Who has admin access and why? etc etc ...

Most of the time, pulling those answers together takes days of manual work across multiple areas of the instance and even then there's not always confidence it's complete.

Two questions for the community:

1. How are you currently tracking configuration health in your instance. Is it manual, automated, or reactive to as and when it needs to happen?

2. When leadership or a project forces the conversation, what's the first thing you wish you already had ready?

Keen to learn how folks are managing this to ensure we continue to build Solcoro in the right way - a way that fixes a problem for folks.

Comments

Yatish Madhav

Hey @James Bevan

"governance work sits towards the bottom of the backlog until something forces it up" - this sounds all to common unfortunately!

Luckily, the Jira REST API works great to be able to pull a full list of spaces, schemes, fields, etc - the hard work comes in when we need to verify and get agreement on being able to consolidate/optimize and archive old spaces. My approach to this over the last year or so has been to grab the low hanging fruit - the Site Optimizer has been a great help! This is things like finding spaces with minimal or no issues or issues last updated more than 3 or 4 years ago and then moving to 2 years, and so on ... Yes, it's manual, but with the sheer number of spaces and proj admins, it works the best.

WRT Jira health, what do you mean? In my Atlassian sphere, it often meant performance of the tools. We had just over 1 million issues and just over 900 spaces a year ago but now down to around half and some users are spotting a performance improvement. Still a way to go ... but it is a positive!

To answer the questions:

1. How are you currently tracking configuration health in your instance. Is it manual, automated, or reactive to as and when it needs to happen? I believe I have answered but it is a slight mix of all 3 - Manual based on the current requirements, Automated to be able to see the "lay of the land" and monitor counts and reactive to when audits or 'true positives' come up to action more specifically.

2. When leadership or a project forces the conversation, what's the first thing you wish you already had ready? Interesting one! I would say a stronger foundation in internal policies around retention, esp with the varied types of projects ranging from internal to client-specific to project-specific to once-off and to add to that, project admins that have over time left the organization so need to manually confirm if spaces are no longer needed.

All that said, I do have to commend Atlassian on the Site optimizer once again ... I have not yet used it much for schemes but will use it to see how those can be ironed out better. And of course, as for third party add-ons that may assist with this, I am always pro-native functionality, mostly due to the cost aspect

Thanks
Yatish

joao zampa_mzucs0

Here is what we do have implemented:

Automated:

Projects that are not touched for 3 months are auto archived, we are now implementing a task that besides the archiving we will be reaching out to project lead to confirm if the project can be deleted. If the project can be deleted, we will try to reduce the number of fields by deleting the ones that were just used by this project
License harvesting: Users my try Jira to see if it works for them but they might decide that it does not. Users might move to other teams that don't use Jira as a tooling. For cases like these we have implemented license harvesting, which is to claim back licenses that are not in use for over 3 months.

Manual:

No one gets Admin role without my final approval, and you will gain access if you are either part of the team or if you are supporting the tool (ITOPS champions). If I notice (dashboard) that I don't see you resolving tickets, your access is revoked.
We are getting rid of Team-managed projects as they are adding so many redundancies on the CF area.
We are working to create a data retention policy, so we are aligned with DPO what can be safely deleted.
Since Admin permission is given to a small number of people, we can control things a bit better
Configured the Authentication Policy in a way that we are enforcing SSO authentication
We know who are the owners of each service account that gets access to our system
We configured the default permission scheme in a way that no external user will get more access than they need

These are the things I can remember now, I hope it helps.

James Bevan

makes a lot of sense Joao - thanks for the comment!

I think we would be able to help enhance that from an automated and continuous perspective when admins are required and requested to make changes from users etc.

be great to connect.

Welcome!

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

Quick Links

Find more posts tagged with

jira

configuration

governance

config