Worst Jira Admin Contest: Overly Complex Workflow

[#1]

Mistake 1

One of the worst workflows I’ve seen is unfortunately, one I built. We were having process problems and thought a comprehensive Jira workflow would solve them. But I’ve since learned that if you’re having process problems outside of Jira, Jira will not magically solve them. The revamped process itself was great, and the diagram explaining it was snazzy, but it all went wrong when I translated it into a 20-step Jira workflow. Users clicked through the statuses as fast as they could just to quickly get to the end. All the statuses and complexity provided no value at all.

Instead of a super long workflow, I recommend breaking your process up into high-level phases. Then, the phase becomes workflow status, instead of every little thing the team does in that phase.

---

Back to intro and mistakes list

[Joseph Chung Yin]

@Rachel Wright -

In our envs the previous admin team failed to properly control WFs configuration rights,  and we have a few old active Jira Software Application projects that at one time having so many users created WF statuses - The biggest offender had an WF with 40+ statuses and every status and go into every other status.

Since we (new admin team) came into the active role of owning the application, those projects' WFs were redesigned working with the key stakeholders and eliminated the incorrect process/thoughts processing on WF designs and implementation.

Have to say it was a job to correct the process after the facts.  Now, everything is under the proper controls and standards for our organization.

Best, Joseph

[Matt Doar]

Oh yes, workflows. I generally state baldly that any more than 9 statuses in a workflow is a smell. It's not always true but it does make me suspicious.

Generally a workflow needs

1. A "new, no work done yet" status
2. A "approved and ready for work to start" status
3. A "work in progress" status
4. A "work has been done, needs checking, deploying" status
5. The "All done, no more work" status

Sprinkle in a few more such as On Hold. Don't add Reopened since it can be searched for with the Change operator in JQL. Avoid Resolved because people get confused with the system field Resolution.

What have I missed?