nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira standards

Giovanny MACARTHUR

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.

Comments

Kathi Paquet

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)

Giovanny MACARTHUR

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.

Kathi Paquet

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.

Giovanny MACARTHUR

Thank you again Kathi.

Mykenna Cepek

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

Also, are you using Roadmaps?

Giovanny MACARTHUR

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.

Thoughts?

Dave

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).

Regards,

Dave

Sergei Gridnevskii

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.

Sergei Gridnevskii

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.

Jonas Börnicke

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. 😉

Giovanny MACARTHUR

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.

Giovanny MACARTHUR

Thank you very much Dave, some good thoughts there.

Giovanny MACARTHUR

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.

Julie d_Antin _Elements__bsgnak

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

Giovanny MACARTHUR

@Julie d_Antin _Elements_ Thank you very much! Bookmarked!

Konstantin Virolainen_p0i1w1

Lots of great points here — having clear standards for each issue type and sticking to them is huge for reporting and avoiding rework.

If you ever want to take it a step further, we’ve been working on AI Copilot — Beyond Templates. It comes with playbooks based on Atlassian’s recommendations that you can adapt for your teams, and the AI can both create tickets from rough notes and check existing ones against your standards.

We just launched it last week and are looking forward to your feedback so we can keep improving it.

Welcome!

It looks like you're new here. Sign in or register to get started.