Standardization - lessons learned?

[Kim-Stacey Kidder]

Hi! I'd love to hear from other Admins re. Jira standards (for example: naming conventions, user permissions best practices, data consistency, etc. …) that you have found to be particularly helpful:  

• Things to avoid?
• Lessons learned/best practices
• Methods - implementation (getting everyone on board)
• Methods - maintaining adherence to standards
• Documentation/resources
• Data clean-up
• Audits
• Additional comments/recommended resources

Thank you so much in advance for your responses! They are greatly appreciated! 

[Haddon Fisher · Accepted solution]

• Disable team-managed projects.
• If I get a basic question like "how can I export these tickets..." three times I write a doc on it in our Confluence's "Atlassian" space.
• As much as possible "teach people to fish" instead of "giving out fish", particularly around Automation. You will be shocked how fast you end up owning everyone's business logic.
• Disable team-managed projects.
• As much as you can, keep conceptually similar groups of projects on the same sets of configurations. For example, you might be able to standardize your project settings across all of your Scrum teams or CS pods. This makes deploying changes significantly less painful.
• Make your custom fields as 'generic' as possible so you can re-use them. This is less critical on Cloud than on Server\DC but it'll still make your life easier.
• Disable team-managed projects.
• It's not entirely scalable, but I try to use the convention "[Project Key\Project Category] - [Issuetype]" for workflows.
• For screens it's a little easier, and I use "[Project Key\Project Category]: [Issuetype] - [Action]"

[Kim-Stacey Kidder]

Thanks, Haddon! Some good stuff here!

[Sam Ayres]

Haha!! I love the reiteration of "disable team-managed projects" @Haddon Fisher. Couldn't agree more!

[Gus Fort]

I would also add that if you are not the lone Jira admin to make sure you and the other admins have a nice standard operating procedure regarding user requests so that you are all on the same page and don't make poor or less manageable decisions just to make that one user happy. It's ok to have a quick chat with each other about long term implications and push back on requests by offering alternate solutions that will make your job much easier.

[Aldo Hoomz]

Hola soy nuevo!!!👋

[Sergei Gridnevskii]

I guess you were hit by a team managed project when you were young and you still remember it.

I use them intensively for non-it teams like HRs, Reception, etc. It removed tones of workload for me - just show team member how to manage them and voila - they do what they want and do not bother you.

[Haddon Fisher]

I was definitely bit by one as a child Sergei Gridnevskii ;) 

I am surprised to hear your users don't bother you though. It seems like every day someone reaches out to me to ask how they can fix\adjust\do something only for me to find out "oh that very basic feature is not a thing in TMP's". 

[Kim-Stacey Kidder]

Yes, like many reports/filters, etc... need resolution, which is not out-of-the-box in TMPs. How do you handle reporting needs for your TMP clients? 

[Sergei Gridnevskii · Accepted solution]

• Enable team managed projects for teams that know better than you what they need. Examples: HR, Business Management, Analytics. They are not IT guys, team managed is what they need.
• Never add users and groups to projects permission schemes. Always use Roles.
• Make custom fields as specific as you can. Avoid using same custom field in another project unless you 100% sure what you are doing. Never use the same name for different types of custom fields. Use contexts for every field, limit it only to project where it is used.
• Never share a workflow unless it is the project of the same team. Every project manager has his own point of view and finding compromise between them will take a lot of time and will cost a lot.
• Try your best to persuade each team to have its own project. Middleware should not share settings with Backend and Frontend. QA should use their own sprints and scheduling. If they work on a same problem - use epics/stories, link issues together. Copy problem description from planning to development to QA using Automation for Jira.

[Sergei Gridnevskii]

Another very useful tip.

Create a project that would solely serve changes in Jira itself. For every config change requested by users create a Jira issue. Whenever possible describe the change with issue key. E.g. if you edit a workflow mark it with [ISSUE-223] in change description. 

It helps a lot to find who made a change and why.

[Haddon Fisher]

This 100000%. Eat your own dog food!

[Kim-Stacey Kidder]

Thanks, Sergei! Some good tips! 

[Maeneth]

@Sergei Gridnevskii 

Same thing happened to me when I change a status in one workflow it is changed automatically in all other workflows which causes a problem from my team.

[Toni-Ann Harvey · Accepted solution]

I've found giving each project their own specific config - schemes, workflows, screens etc to be much easier.

On the surface it seems like more work, but it really isn't!

Even if i am copying a scheme, i rename to specific project - this allows me much more freedom when it comes to customising the project to suit their needs and not having to worry about the impact that could have on other projects if sharing the same config. We have some projects using the shared config and I personally find it a nightmare to manage changes. 

[Sergei Gridnevskii]

Yes, same for me. If you forget/don't notice that a config is shared a minute after you make a change you have an angry team member from another team asking you to roll back changes.

For me a rule of a thumb is to make a copy and make changes in a copy. Unless all teams agree that they need this change.

P.S. One of the strangest "features" in Jira is that when you change a status in one workflow it is changed automatically in all other workflows without any warnings. E.g. if you rename Done to Complete all projects will have Complete status.

[Jamie Hamilton]

I like this method too - often new projects need bespoke/ new fields for different reporting outputs etc, so this enables changes to fields and what not without impacting the other projects. 

But I have a couple project templates that are kept up to date and reviewed with the project managers, kind of acts like a master config which saves time! 

[Kim-Stacey Kidder]

Thank you, Toni-Ann, Sergei, and Jamie! This is helpful!