I was inspired by this discussion topic: https://community.atlassian.com/t5/Jira-Cloud-Admins-discussions/How-do-you-keep-track-of-the-sprawl/td-p/2001305 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.
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.
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.
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.
@Dave Rosenlund _Trundl_ - 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!
5 comments