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.
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.
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).
Some other tips I coach on teams:
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.
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. 😉
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events