Standard Issue Types and Workflows

[Isabel.Mills]

Hi, we are continuing to standardize the way our teams leverage Jira Software projects with standard issue types and workflows. Has your firm implemented standard issue types and workflows? If so, how many (of each, respectively)?

Thanks in advance for sharing!

[Josh Costella]

Our Development teams share a workflow across their standard issue types. However, the workflow is built with "All" transitions on each status so the teams can still "customize" how they use their workflows in their boards while still allowing us to use a templated workflow. 

[John Funk]

Hi Isabel,

Yes, our team has implemented standard issue types and workflows across all product teams. However, we actually have several issue types because we are a heavy content company with lots of different types of content that we want to track. 

And then we have a main, rather large workflow, for the vast majority of our issue types. So the number doesn't really matter as a guide for you, The question becomes, what is it you are wanting to track and do those items follow very different workflows or are they fairly similar. 

[John S Davidson]

We have a similar situation with one main workflow.  So far it is sufficient for our issue types, if a little too granular.  The approach we're taking is "don't fret over the statuses that don't apply".

Its mostly for Scrum projects, and is showing to be unsuitable for Kanban.  As we have very few of those its still being used with the understanding that the statuses are loose titles and used more to show progression.

At some point in the nearish future I anticipate a review of at least the workflow for Kanbans.  This may or may not lead to multiple new workflows for Kanban projects, and potentially spark a review for Scrum style projects too.

I'd echo @John Funk in asking what is it you're looking to achieve here?

Is the standardisation of Issue types and workflows to provide a common language for describing the work for reporting/management understanding, or is it to allow for clearer prioritisation and understanding for issues passed between/issues causing dependencies in different teams?

If the teams work fairly independently of each other I'd suggest workflows that work for the teams rather than creating a common set that tries to cover everything.