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

How do you keep track of the sprawl?

Chris Thomas
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.
April 13, 2022

We have about 500 users and over 200 projects, and over 500 custom fields.

How do you guys keep track of what's going on in your Jira instance?

14 comments

Comment

Log in or Sign up to comment
Stéphane Veraart
Contributor
April 13, 2022

Less Jira/Project admins with rights to change fields and workflows and more governance by using standardised and reusable project templates.

Like # people like this
Eglė Kaziulionytė
Contributor
April 13, 2022

also, unified request/demand management towards Jira admin team - that is, have a dedicated place and rules for users to request anything for their projects. Simple tracking, centralized place for decisions (e.g. if you receive complex requests such as new plugin installation or so, you can involve higher team members to approve/reject the request and so on) 

Like # people like this
Sergei Gridnevskii
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.
April 14, 2022

Standardization gives less flexibility. And users hate us more.

Like Darshan Mandhane likes this
Paula Hidalgo
Contributor
April 15, 2022

There needs to be guidance to the users as to what can be tailored and what cannot be tailored.  Having guiding principles for Jira design can help users understand the 'why' for the less flexibility.  For example, a principle everyone can buy into is having a stable, performant Jira instance.  Other principles to consider are

  • common reporting across your company may require common status values (limits workflow flexibility)
  • increased efficiency when templates are used by lowering the learning curve when users are expected to work in more than one project, allowing teams to collaboration on best practices
Like # people like this
Lorenzo Phillips
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.
April 13, 2022

I absolutely agree with @Stéphane Veraart

To maintain a healthy environment, you'll need more restriction on who can do what, standards, project templates, etc. However, I would also add that you should restrict the use of team-managed projects (if possible) as this allows statuses, workflows, fields, etc. to be generated outside of Jira admin control.

If you're looking for a way to clean up your instance fast and monitor it going forward from a centralized location, I have written an app called Instance Auditor (Jira) that may be useful to you--shameless plug I know, but our customers have been very happy with the app. If you decide to give it a try, I'd welcome your feedback :).

Like # people like this
Amir Katz (Outseer)
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.
April 13, 2022

Here's my (non-exhaustive) list :

1. Have a small, trusted group of Jira admins

2. Establish best practices (e.g. "Do not create custom field with same name as an existing one")

3. Clean up entity sprawl - get rid of unused statuses, screens, custom fields, workflows (=inactive ones) and all kinds of schemes (screen, issue types, etc.)

4. Share schemes across projects - permissions and notifications

Like # people like this
Stéphane Veraart
Contributor
April 13, 2022

Thanks for you additions, @Amir Katz (Outseer) 

My answer was a very short summary of your more extensive answer.

Like # people like this
Anne Saunders
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.
April 13, 2022

This is exactly what I came here to say. The standardization has REALLY helped my workflow!

Sergei Gridnevskii
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.
April 14, 2022

I oppose sharing schemas. Because when one team makes changes immediately another team member jumps in and runs to me and asks to remove changes. It is easier for me as admin to have a scheme per project. 

Maybe if you have only one team it will work. Me having 10+ teams am too lazy to negotiate changes with everyone. I have default schemes which I copy every time I create a new project. 


Like Shawn Jamison likes this
Anne Saunders
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.
April 14, 2022

I'm just mean about enforcing them and no one else is allowed to create schemes. 

Like Elizabeth Nixon likes this
Sergei Gridnevskii
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.
April 13, 2022

1. I use context for every new custom field where I select only projects and issue types that require this field

2. I have a default fields config where all fields are hidden. When I add a new custom field I go to this default config and hide the new field. Whenever I create a new project I make a copy of default config with empty fields and turn on only fields I need nothing else.

3. I use roles for projects. Every user is a part of several groups. Whenever anyone needs access to project I apply a role to a group. Or add the user to the group. 

4. Important changes should be documented. I have a project Jira in Jira where any employee can put tasks for me. Whenever I do a change in config I put the ticket number in description or in rule name. This helps me to find out who requested the change and why.

Like # people like this
Karen Rogalski
Contributor
April 13, 2022

All excellent suggestions which will stop the chaos.  I would recommend to use Jira to track all requests and changes. All tools requests are tracked by Component: User Permissions, Custom Fields, Workflows, etc. and by team/Jira project.

Above all, KISS it.  For example, if a request comes in for a new Status named READY FOR TESTING and you already have another Status named READY FOR TEST, then use that. Minimize always creating new Assets-- Statuses, Workflows, Resolutions, etc.

Like # people like this
Amir Katz (Outseer)
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.
April 13, 2022

this is one of my guiding principles - use existing entities if they have the same type (e.g. for status, the requested status category) and if the name is close enough.

Another best practice - we migrated 2 on-prem Jira servers to the cloud and now we have large number of unused entities. So I would take an existing one (status, resolution, CF) and rename it as per the request thus avoiding creating new ones.

Like # people like this
Ken Siskind
Contributor
April 13, 2022

I made a JSM project for Jira and Confluence help requests to help track what people are asking for and keeping it centralized.  Like others, I have a few trusted other admins who can self-manage their own subset of projects.   I also agree with the other great suggestions listed above.  

And I also shut-off letting people create "team projects".  When I had this on in the past, people hit limits and then I had to convert them to company managed projects.  People also don't know how to set the permissions for those projects and then they are left wide open when they shouldn't be. 

Like Amir Katz (Outseer) likes this
Amir Katz (Outseer)
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.
April 13, 2022

Good point. I tell people, "if you create a team-managed project, we (the Jira admin team) cannot support you." That usually works...

I will look into blocking this option completely.

Rilwan Ahmed
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 13, 2022
Stéphane Veraart
Contributor
April 13, 2022

@Rilwan Ahmed : the assumption there is that @Chris Thomas is using a Cloud instance. In which case the option of removing the creating Team-managed is a good choice in these circumstances.

In other circumstances, for on-premise the recommendation would be to limit the Project Admin permissions to basic only instead of advanced admin rights.

Like # people like this
Anne Saunders
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.
April 13, 2022

I have never looked at our audit log before! Of the first hundred logs, 89 are my actions, so I'm not worried, but I'm super glad to know about a place I can monitor!!

Sergei Gridnevskii
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.
April 14, 2022

BTW audit log has REST API and I plan to have a scheduled job that will extract logs once in 3 months and store it in appropriate location. Jira cloud deletes logs after some time and it is a good idea to backup them for inquiries.

Like # people like this
Rilwan Ahmed
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 13, 2022

User Management:
- Create appropriate groups and add users to it. 
- Map groups to projects. Use a naming policy. example: For project ABC, group name like  ABC-Team, ABC-Admin etc.
- Add only the real users with Jira administration knowledge  to jira admin groups. This will restrict other users from creating custom fields, Workflows etc. 
- Occasionally send Project admins/leads the list of project users and ask them to review. This will be helpful in maintaining the license count. 

Projects:
- Categorize projects
- Try to re-use schemes (workflows, screens, issue types, priorities etc). i.e create project with shared configs for same category. 
- Use context for fields

Global Permissions:
- Add appropriate groups for global permissions. Not all users require all permissions. 
https://support.atlassian.com/jira-cloud-administration/docs/manage-global-permissions/

Audit log:
- On Random days, check system --> Audit logs. You will come to know what all is happening in your jira

Like Amir Katz (Outseer) likes this
Amir Katz (Outseer)
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.
April 13, 2022

Minor comment - AFAIK, priorities in the cloud are global. There is an open feature request to have priority schemes in the cloud.

Sergei Gridnevskii
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.
April 14, 2022

Yep, but you may hide global priority in default field configuration and use custom field with same name with many contexts.

Tanya Christensen
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 13, 2022

@Chris Thomas This page has some good advice:  https://www.atlassian.com/blog/jira-software/human-side-scaling-jira-software-governance-custom-fields-admins

Granted it's from a few years ago but the advice applies. 

Additional resources and Marketplace apps

These are but a few but have some good options for managing/grooming schemes.

Like # people like this
Paul Cooper
Contributor
April 13, 2022

From the original post the number of custom fields looks a bit high, from my sea gull view that looks like 1 custom field per user.

I would do two things:

1) standardise your project workflows - aim for a standard set (with 200 projects that might be as many as 20 standard workflows - but 20 is easier to manage than 200)

2) group your users - as others have suggested

and then make a critical analysis of the custom fields to de-duplicate and standardise them - along the way expect lots of user resistance but hit the low hanging fruit first i.e. fields with low project use.

 

p.s. you cannot do this in a day, you have several weeks/months of activity ahead of you.

Like Mike Rathwell likes this
Amir Katz (Outseer)
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.
April 13, 2022

Re de-duping fields - this is easier said than done, speaking from (painful) experience - replacing custom field A with B can be a lot of work, especially if you have

a) many issues, projects and issue types using this field

b) field is used in workflows (conditions/validators/post-functions), automations and other entities that refer to fields.

Sergei Gridnevskii
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.
April 14, 2022

That's why they have contexts in Jira. Every field with a name and a type can have any number of contexts where you put various initial values, options (in case of lists) and even insight queries. I recommend using contexts as long as they eliminate many problems.

Summer Hogan
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 13, 2022

Seems like everyone above has some very valuable information, but to add to that we use a roadmapping/feature tool called Aha that integrates with Jira. It gives a more high level view of features and initiatives than Jira does and Jira and Aha keep each other updated. Just thought it would be helpful given is it is a more birds eye view of what you have in your Jira instance. 

Mike Rathwell
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.
April 13, 2022

There are some stellar thoughts here. It would seem it all boils down to governance. This is a true enterprise class environment and needs to be treated as such. As soon as you do that, you start down the path to honest manageability and rigorous support of the enterprise while maintaining the measured method of supporting the entire organization.

Like # people like this
Paul Cooper
Contributor
April 13, 2022

Your analysis is correct, governance is key, be careful to avoid the trap of becoming 'the process police' ! 

Whatever governance model you select should aim to assist >85% of users, 10% you will need to work on convincing that good governance will improve their lives long term and 5% of users will resist forever so just accept that apply governance and move on :-)

Best of luck with your project to bring this under control.

Mike Rathwell
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.
April 13, 2022

You hit the nail on the head, @Paul Cooper , If we try to square peg all the people, lots of them will be unhappy with their lot. I have implemented the toolset to where it had 100% penetration across the organization while maintaining rigorous governance. It was the combination of rolling common processes together where possible but also the snowflake processes supported but in the context and view of the entire organization.

One comment of many that told me I had succeeded was when the person that ran payroll told me she would never work anywhere she couldn't manage her work in Jira.

Like Stéphane Veraart likes this
Paul Cooper
Contributor
April 13, 2022

Hi Mike,

"One comment of many that told me I had succeeded was when the person that ran payroll told me she would never work anywhere she couldn't manage her work in Jira."

This type of comment can be treated one of two ways:

- aggressive user threat

- someone who does not understand how consistent processes benefit them

I have encountered this personality many times too (not always in a Jira context), there are a few strategies to tackle them:

1. Majority rule - if nearly everyone else is using common and consistent tools then use this and then ask the complainants to explain to their line managers why they need an exception - oh yes, and then give that manager a support cost specific to the customization i.e. you need xyz to support it

2. Call them out - give them a window of time to adjust and then migrate their work the consistent process - blunt but sometimes you just have to tell people this is what is going to happen and when but don't expect any Christmas cards from them. Sometimes people say 'I am going to leave if xyz happens'. As long as the reasons for the change have clear benefit to the business and are mandated by the leadership team then it's not your problem if someone gets the hump and leaves.

3. Explain how they benefit from the standard process - this can be very effective if you can factually identify the hidden cost of managing non-standard workflows and show how that cost affects the bottom line e.g. less cash available for pay or bonuses as you had to outlay all this support cost. In other examples, like custom fields if users can minimise custom fields and have fields that they can use in different projects but are the same field then that can simply be explained, in a large tier 1 telco supplier I saw 6 x custom fields all named "Project", that made finding the Project field that you needed rather hard - once this was explained we agreed that one field call Project would suffice and everyone was happy.

4. Use the power of management - go above the complainant, explain what needs changing and why to line managers and get them to change their employee's behaviour - this works well if employees you need to change have some influence on your life that you might see as a  threat e.g. paying you

I think, in your case with so many disparate teams and projects you need a leadership sponsor, someone in your executive board responsible for change management - top-down may be the only way forward for you.

Best of luck

Paul

(p.s. as VP of Engineering I am the top-down change driver in our company so my life is a bit kinder and we are a lot smaller than you)

Like # people like this
Mike Rathwell
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.
April 13, 2022

In this case, @Paul Cooper , it was a human understanding the benefit of a common environment run for the common good. She got how much it helped her and that her project was linked with AP, HR, and she had her own service desk.

I didn't have a leadership sponsor; I was largely self directed at that time. However, I'd been rather successful at making my user base happy and improving the company's lot so... they let me do stuff.

The only complaints I got was that there was one of me and they all wanted on board the Atlassian bus.

Like # people like this
paul grant April 13, 2022

why 500 separate projects ? can you explain why the huge number - what is the correlation / break down on why you've reached this amount of projects ?

Anne Saunders
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.
April 13, 2022

It's easy to do in a customer facing shop where every software project has its own documentation, repos, hosting solution...we're a SMALL shop, and we have well over 100 active ones.

paul grant April 14, 2022

using adv roadmap (rm), teams, components and initiatives can keep the sprawl down. 

a custom board or adv rm plan for each sprint squad or kanban team can also help.

the plan view adv rm gives, makes it easy to see the overview of where each team / sprint / initiative or "component" level is going / doing. you can quickly swap between efforts by a quick adjustment to a filter on the "overview" plan board.

it does depends on what you're trying to show and achieve - but having hundreds of small projects seems to be a big overhead

Paula Hidalgo
Contributor
April 15, 2022

The ratio of projects to users is 1 for 2.5 users.  That may be slightly high but it is a function of how many template only and sandbox only projects are included in the the 200 project count.  We have empty projects for the templates used to create new projects on our instance. We also have 'sandbox' projects to allow users to learn workflows without adding issues to their assigned team projects.

Jesse Kanner
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 7, 2023

At Disney corporate IT we had thousands

Paula Hidalgo
Contributor
April 15, 2022

I agree with the suggestions above.  In addition, you may want to consider tracking the design element sprawl by getting snapshots of your instance's growth.  I highly recommend @Rachel Wright book on JIRA Strategy Admin Workbook. She has good suggestions on how to clean up a 'Jira swamp'.  If you have a cloud instance, scripting with API calls will be your best friend. 

Like Karen Rogalski likes this
Jesse Kanner
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 7, 2023

Locking down admin is a good start - and bias towards standardization also good.

This said, I suggest though that you hold a monthly or bi-monthly Zoom call that is open to all users to pitch ideas around together. Your job is to carefully capture those ideas and requests in a group setting - and report back on the next call your analysis of the request.

They key here is to be both open and accessible while at the same time slowing down the volume of requests. Sometimes multiple requests can be combined into one change request - thus achieving standardization... and letting your users feel empowered. 

TAGS
AUG Leaders

Atlassian Community Events