Is better to have fewer, more complicated workflows, or a larger number of simpler workflows?

[JasonF]

I know workflows have a large impact to your JIRA system performance, I just haven't seen anything that details if that's just volume based?  Or complexity?  Bit of both?  Just curious if anyone has any experience with this.  

Let's look at the following scenario:

• 5 groups of 5 related projects
• Each project wants their own custom workflow

You could implement this a number of ways, but let's just say you are choosing between:

25 unique workflows, 1 for each project, but all relatively simple.  No complicated post functions/conditions/etc...

5 workflows, 1 for each group, but more complicated with conditions and validators, as well has post functions etc... based on Project/Issue Type/etc...

I realize of course being an Admin on 25 unique workflows would be a pain, but the focus of my question is around performance.  5 Complicated Workflows?  or 25 Simple ones?

Thanks!

[Sebastien Ribiere]

Let's consider both cases.

If there are many simple workflows

3 problems here

• many similar workflows which have only details that differ (for example state names)
• complicated to administrate because of this number of workflows => great effort to combine similar workflows
• sometimes a very complicated workflow => lost users that don't know how to handle JIRA issues (Which button to click? What to put in each field? etc...)

If there are only a reduced set of complicated workflows

2 problems here :

• users can be lost when interacting with JIRA issues if the workflow is too complicated.
• You will be forced to create new workflows with almost each new project because each project has its own needs and complicated workflows aren't always a good solution.

I think the truth is between the 2 options : I think I would create one scheme of simple workflows for usual little projects, one scheme for medium projects with more complicated workflows ... and for very huge projects create custom workflow schemes on demand.

[Rob Horan]

What's better is providing solutions for the needs of your users.  Forcing them to use a small set of workflows because you'd prefer not to manage a larger set does not benefit the users of the system.  The question is this:  is there a legitimate need for multiple workflows, or can some be combined, making use of roles/groups and workflow conditions to determine pathways?

[JasonF]

Hey Robert, thanks for the response!  Its not about the management of the workflows, its a performance question.  In the "Scaling Jira" article from Atlassian:

https://confluence.atlassian.com/enterprise/scaling-jira-461504619.html

The mention that "The configuration attributes that affect JIRA speed the most are custom fields and workflows."  I'm just curious if that's purely based on the active number of workflows, or the complexity of the workflows.  I agree the most important piece is providing the right solution, but doing so in a scalable way.  So when a users asks me for something custom, I'm just wondering if it would be more performant to give them a simple custom workflow, or complicate the existing workflow so it can be shared across all of their projects, but still meet their needs.  Thanks!

[Rob Horan]

I understand    I'm not a fan of having to add a ton of custom fields, workflows, etc.... sometimes there just is no getting around it.

[Joe Pitt]

I prefer to have one workflow for each issue type regardless of project, although some issue types may share a workflow. So if you have 10 issue types you'd have at most 10 different workflows. I've often found there aren't any really valid reasons for say project A to handle Tasks differently than project B. If there is, they probably aren't really the same work and should have a different workflow and issue type name. The simpler you make the workflow the easier it will be to figure out why something isn't working and to make changes, which will eventually be needed. I doubt there is any meaningful difference in performance since the logic for any given step won't differ too much from a computing resource viewpoint.

[Rob Horan]

In my organization we definitely have different teams using the same issue type in different projects in very different ways.  A "task" to a development group is very different than a "task" to business users, for example.