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. 

[Sergei Gridnevskii · Accepted solution]

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.

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

[Laura Campbell _Seibert Media_]

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

[Giovanny MACARTHUR]

@Laura Campbell _Seibert Media_ Thank you very much! Bookmarked!

[Dave · Accepted solution]

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

[Giovanny MACARTHUR]

Thank you very much Dave, some good thoughts there. 

[Kathi Paquet · Accepted solution]

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. 

[Kathi Paquet]

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.

[Giovanny MACARTHUR]

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. 

[Pavol Harvanka]

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

 

[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]

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. 

[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? 

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