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

Team, I am working with my organization to establish some Jira standards for our users to follow. Is there a good basic list of standards I could use as a starting point? Some examples I have thought of include ensuring particular fields are utilized for a well formed story (Summary, description, acceptance criteria, story points, assignee). Utilization of epics consistently across teams etc. I think it is important to lay out some standards so we can report consistently between teams and also provide some basic Jira 101 for people as they start out. Any thoughts, ideas are greatly appreciated. 


5 answers

3 accepted

4 votes
Answer accepted

The biggest issue for me as admin is 100500 custom fields that developers add here and there without thinking. So in this case policy would be 

1. Use unique fields configuration for each project where you turn off all fields not related to your project

- or -

2. Use Contexts for each new field where you list only one or two projects


And of course never never never let them use custom fields with same name. Tell them to be creative in choosing the name or just delete the second field. If they ask you why - tell them because I said so.

Thank you Sergei, at this point I am not sure if anyone is using custom fields. I am leaning toward locking that down if we can until we are more mature then allowing the use of custom fields. But I will admit I am not familiar enough with custom fields and scenarios around how we might use them to make that call at this time. 

Here's a good resource for determining when and where to create custom fields: guide to custom fields

Like Giovanny MACARTHUR likes this
3 votes
Answer accepted
Dave Atlassian Team Apr 05, 2021

Hi @Giovanny MACARTHUR,

Generally I agree with what @Kathi Paquet has suggested... good Jira standards have always been really important for running successful projects in my experience (both at Atlassian and at other companies I worked at prior to joining).

Quite often it can vary depending upon the issue type - for example you might want to have a well defined description template for bugs to ensure that all the required information is populated (you might have noticed that public Atlassian bug descriptions follow quite a strict template). You'll definitely want to ensure that people clearly document all the steps (as well as the environment) required to reproduce a bug so that it can verified and you can verify that it's been fixed.

For features / stories you might want to be a little more lenient but I think that acceptance test criteria is still essential.

Ensuring workflow state is up-to-date and that assignee information is correct is also important (as is correct setting of components and labels if you're using them). We've actually setup automation in our project that "nags" developers if they fail to set these. 

In our team we also encourage that developers comment on updates and even during transitions just so that there is a clear audit history of what has happened. 

Unfortunately in my experience developers don't always see the value in doing this sort of thing (as the real benefit is often at the PM or management level). If you're able to tie back tangible benefits to the end user then this can be really useful. For example we encouraged the user of labels when reviewers checked and implementation or verified a bug fix and were able to product some stats that showed the effectiveness of the process.

Quite often you just need one or two people to set a good example and for others to see the benefits (which are often when you need to look back at what you've done or why certain decisions were made).



Thank you very much Dave, some good thoughts there. 

Like Bridget likes this
3 votes
Answer accepted

Some other tips I coach on teams:

  • Epic format (the Summary and Epic Name to be the same) 
  • Epic Description and Acceptance Criteria
  • Keep Epic Kanban board updated (status)
  • Update your stories/tasks daily (hrs logged, comments on status, etc.)
  • Keep the board updated (status)

Thank you Kathi. Question on #3, do you keep epics on a Kanban board and then the stories on a scrum board or do you just have everything in a Kanban board? I ask because we do have a hybrid someone used here with both Kanban and scrum boards. 

I have my epics on a separate Epic Kanban  board for the Product Managers, Product Owners, and/or Epic Owners to manage.   The agile teams have their stories and tasks on their  team scrum and/or kanban boards.  I have the team boards configured to show the epic panels. 

Like # people like this

Thank you again Kathi. 

You are welcome.  I have created one sheets (cheat sheets) for newbies as a reminder and posted on Confluence to help them.  One thing I recommend is having an Atlassian Governance or Atlassian Community of Practice where there is a limited # of JIRA Admins and where people can share and learn. 

I know you were asking about user checklist, I would also think about the Jira Admins. Often, I see companies give JIRA Admin rights to 13 + people and then fields are being created and there is no naming conventions.  For example, the team created a status "In-Progress" and another team create another status called "In Progress" which lead to inconsistency in reporting and challenges for creating canned AIO reports, etc.

Like # people like this

Those inconsistencies are one of the main reasons I want to establish some standards. We actually don't have Jira admins yet, but we are working on bringing some in. We are barely crawling at this point. 

Like Kathi Paquet likes this

Regarding #1 - Automation rule to stop nagging everyone all the time 


Like Bridget likes this

Our developers do not work all that well with only encouragement for maintaining their Jira issues. One thing I like to use are workflow conditions and validators. With those you can for example set certain fields as required when users want to transition issues, meaning they cannot transition the issue with said field being empty or different from a certain value.

There is much more you can do with conditions and validators, this is just how we use this feature. Maybe that helps. 😉

Jonas, that is a big help. I am thinking of implementing something similar. Not allowing a story to move forward if certain fields are not taken into account. 

Like Jonas Börnicke likes this
0 votes
Mykenna Cepek Community Leader Apr 05, 2021

Are these teams are using Next-Gen (Team Managed) projects, or Classic (Company Managed) projects?

Also, are you using Roadmaps?

Currently we are using both Next-Gen and Classic but we are going to switch to Classic and move projects from Next-Gen. 


We are not currently using roadmaps, but that is one thing I was thinking of incorporating into our standards. Required fields to enable the roadmap functionality. 


If you have enough budget consider using Advanced Roadmaps. They are very good in strategic planning, you can create plans for years. No fields are needed, this plugin will do all the work for you.

Like # people like this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events