Jira Workflow Separation of Duties

The JIRA Administrator and the Scrum Master were not seeing eye-to-eye. The Jira Administrator wanted to get some firm rules in place regarding who would be allowed to transition issues between different statuses in the workflow. The Scrum Master was vigorously resisting this effort.

“Everything is running smoothly,” the Scrum Master argued. “The team is under a lot of pressure to meet our deadlines, and we’re handling the separation of duties in the Jira workflow just fine as it is. The last thing we need is to clutter up the process with a bunch of unnecessary rules!”

“Sure,” the Jira Administrator replied, “everything is running smoothly and nothing has gone wrong…yet. But if we don’t put some rules in place regarding who can do what, you can bet that sooner or later something will go wrong. Personally, I’d rather stop problems from happening than wait until all hell breaks loose and then have to deal with it. Besides, would you rather get this handled now or risk seeing the problems crop up and the rules put in place six days before we ship?”

Grumbling, the Scrum Master relented.

What does it mean to have a separation of duties in the Jira workflow?

Having a separation of duties comes down to having a set of rules that govern the workflow. Jira already lets you control which statuses you can transition between, such as from open to closed, open to in progress, or resolved to verified. The idea here is to add a set of rules defining who is authorized to make these transitions.

Whether you’re aware of it or not, you may already be using separation of duties in your Jira instance. When you add components to a project you are given the option to designate someone to be the component lead or to be the default assignee for that component. For example, all user interface issues would be auto-assigned to the UI Lead. When you use these designation options you are putting a separation of duties into place.

Why do you need a separation of duties in the Jira workflow?

Just like in a well-run accounting system, a separation of duties can provide “checks and balances” in the JIRA workflow, ensuring, for example, that things that ought to be double-checked actually are.

Not having rules in place governing the separation of duties is like giving everybody on the team read/write access to all of the code. That’s awesome…until someone does something foolish. Then, suddenly, it’s not so awesome after all.

What sort of things do people do when there’s no separation of duties in the JIRA workflow? Here are some examples that I’ve seen in the field:

  • A developer wrote some code for a bug fix. Assuming that his perfect code wouldn’t need any verification at all, he closed the bug without having the fix verified by QA. Once the issue was closed it no longer showed up on anyone’s to-do list. The fix never got verified, and no one noticed what he’d done…until the bug showed up in production.
  • Someone in development closed a support issue without first checking with customer support to see if the customer was actually satisfied with the fix. Just like in the bug fix example above, things didn’t go well when the answer turned out to be “no.” The customer’s problem was not resolved, and they were deeply unhappy about their problem being dismissed.
  • A Project Manager added a new feature to the release without talking to anyone in development about (a) whether the desired feature was technically possible, (b) if there were any gating issues, and (c) how this addition would affect the schedule. As you might guess, the results were not pretty.

What specific rules should you put in place?

Unfortunately, there’s no “one size fits all” answer here. When thinking about rules, imagine a workflow transition as signing off on a piece of work.
For example, when a developer transitions an issue from “open” to “resolved,” they’re saying “I fixed this and I believe that it works.” When QA moves that issue from “resolved” to “verified,” they’re saying “yes, I checked it out, and the fix is good.”
Depending on the specifics of your situation, here are some rules that you may want to consider putting in place:

  • Closing customer support issues – If you’re tracking customer issues in JIRA, whether or not you have JIRA Service Desk, then the rule is that only Customer Support can close a support issue.
  • Verifying bug fixes – If Development and QA are different teams, then the rule is that only QA can verify and close bug fixes.
  • Adding issues to a release – Only the Scrum Master should be allowed to schedule a story or a feature for a sprint. Adding a new feature to a sprint will doubtless affect the schedule. If you add a new feature that will take four days to develop and a full day to test, then the schedule has to be updated accordingly. Either the sprint has to be extended by a week or something has to be pulled out of the sprint. Either way, only the Scrum Master has the power to make the call.
  • Verifying documentation – If the issue has a component that requires documentation, then the rule is that the Tech Writer must sign off on it. This is a prime example of where a more complicated workflow relies on separation of duties. Consider the workflow for documentation, below. It may seem overly complex, but it enforces a key rule of software development: you don’t verify your own work.
    1. The Tech Writer writes the documentation for a new feature.
    2. QA reviews the documentation for accuracy.
    3. Development adds the documentation files to the application.
    4. QA verifies that the documentation is in place, that it’s the right version for the release, and that it’s formatted correctly.

What if you’re using Jira for something other than software development?

Regardless of how you’re using Jira, the concept of separation of duties in Jira workflow is always the same. For example, say you’re using JIRA in Human Resources to track job applicants through the hiring process. Each applicant would be entered into the system as an “issue” and each transition would be an approval to go on to the next step. The workflow might look like this, with a rule governing the transition between each step:

Jira Workflow
Jira Workflow

In this workflow, the transitions to “Make Offer” and “Move to Onboarding” should be restricted to the hiring manager. It’s likely that there will be some negotiation around compensation or start date, and only a person with the authority to negotiate should be allowed to move the issue through these steps.


Without a separation of duties in your Jira workflow—with clear rules governing the transition points—anybody can do anything. Which, as I said earlier, is fine until something goes wrong. Then, suddenly, usually at the worst possible time, things are pretty far from fine. The trick is to define the rules so that they seem completely natural, as if they describe the logical progression of events. If you get it right the workflow itself will not become a bottleneck, and the rule will not get in the way of the team being able to actually get things done.

If you need assistance with this or any other aspect of making the most of JIRA, Coyote Creek can help. As Atlassian Platinum Solution Partners we have extensive experience helping organizations leverage Jira to its greatest advantage.