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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Tips for Controlling "Sprawl" in Jira

Hello Everyone!

I was inspired by this discussion topic: that I wanted to share some tips from my personal experience. I also want wanted to try and tackle this from two directions. I want to offer tips for admins around the things that you can do as a steward of your Jira instance balancing the best practices and user desires. But, I also wanted to use some insights for end users to help provide more transparency of the “things behind the curtain“, so that you have a better understanding as to why an admin will ask for a compromise or reject a request and the things you can do to help control sprawl yourself.

What is “sprawl“?

Let’s start by defining what I’m talking about. When I think of sprawl, I think of the increase of “single use“ objects in Jira. Some of the biggest offenders of this are things like: custom fields, statuses & resolutions.

These aren’t the only offenders but they are the easiest ones to ignore by hiding that which you don’t want to see regularly instead of consolidating and cleaning things up.

What should you consider as an Admin?

Here are a few tips you should consider when user request changes to Jira.

When a user makes a new request:

  • Do you have something already built that will satisfy the request?

  • If not, do you have the ability to fulfill the request with a component/object that can be reused in the future?

  • Will completing this request impact any other teams in a negative way?

On a semi-regular basis:

  • Review the objects that have been created (e.g. custom fields, screen, unused/backup workflows, etc.)

  • Remove, clean items that are no longer needed (probably best to verify with users before removing)

What can end users do to help too?

As an end user, you play just as important of a role in helping to prevent sprawl (if not a more important one!). Here are some things to keep in mind that you can do to help prevent sprawl.

  • Be aware that the more unique objects (custom fields, screens, resolutions, etc.) your Jira Instance has, the greater impact it will have on the overall performance of Jira. (i.e. it can make Jira slower to load for you).

  • When your admin rejects are request or proposes a compromise, they aren’t trying to avoid doing the work, they are trying to balance providing you with the the tools that will make your job easier, which also trying to be conscious of the impacts to the entire instance.

  • When possible, try to keep your admin informed when something is no longer being used that they may clean up.

If you believe I have missed anything important, or I have misrepresented anything, please keep me honest in the comments and I will be sure to update the article.

Have a great rest of the week!


Great article, @Jimmy Seddon  👍

There's one thing I would add to the When a user makes a new request: section. 

When users make an "I want" or "I need" request help them rephrase their request in "the problem I am trying to solve is" or "my business need is" language.  I.e., help them to see their may be another, better for the greater good, way to address their need.

Thanks again for sharing your tips!


Like # people like this

Nicely done, @Jimmy Seddon. Adding my two cents:

In many companies there's another important aspect of sprawl: keeping a lid on the number of projects and major components.

Some companies allow teams to take control of spinning up and customizing new projects and of course that's fine if it works for them.

But much of my experience has been with shops that have projects (generally equating to products) with a long shelf-life and in those situations having a stable top-level 'taxonomy' pays off. I think it's not unusual to have engineers jumping from team to team and having a long-term project history for someone to refer back to, and having consistent issue types, workflows, permissions, screens, etc. to minimize the relearning, makes transitions smoother. It also helps with mgmt oversight, and it obviously cuts way down on admin-level maintenance.

Of course the downside is that teams need to agree on changes to the common workflow, but in my experience getting teams to that shared understanding of best practices is a feature not a bug. 

Like # people like this

Very well written article  @Jimmy Seddon . I am sharing it with my teams and the admin. We get various requests either for new fields, new field values or making fields mandatory. It becomes hard to explain the reason for denying a  certain request - I am sure I'll keep  sharing this article.

Like # people like this
Jimmy Seddon Community Leader May 11, 2022

@Dave Rosenlund _Tempo_ - Excellent point!  Providing the issue that needs to be resolved and allow the admins to offer the best solutions to the problem.

@dave_drexler  - I really appreciate the insights!  I have not personally encountered this issue so thank you for sharing.

@hhegde Thank you for the kind words I appreciate it!

Like Dave Rosenlund _Tempo_ likes this

Super job @Jimmy Seddon !  Thanks,

Like Dave Rosenlund _Tempo_ likes this


Log in or Sign up to comment

Atlassian Community Events