What are thoughts on using transitions in workflows?

[Rebecca Hylek]

We recently migrated to Jira Cloud and our team is preparing to do some major clean up of workflows, etc.  Currently very few of our workflows have transitions.  In my background, using transitions was common and preferred by our users.  

I'm curious how many organizations are using transitions vs no transitions and thoughts on the pros and cons of your experiences.

Thank you!

Becky Hylek

[Danno · Accepted solution]

@Rebecca Hylek, Going back to your original survey question, I would say about 50/50. For my development teams, it would qualify as the simple "no transitions you described. Four status choices with the All transitions.

On the other side of the fence is my home-brewed mini-ERP projects. Manufacturing and Purchase Requisitions have a heavily constricted workflow that totally relies on automation rules to make it happen.

[Rebecca Hylek]

Perfect, thank you Danno!

[Nic Brough -Adaptavist- · Accepted solution]

That's an interesting question, it provokes a load more.

If, for some strange reason, you've been reading a lot of my answers here in the community, you'll have seen me say "Jira is an issue tracker" quite a lot.

Whilst that is generally right, a lot of people question it, as they prefer to say "it is a workflow engine".  They're not wrong, I just prefer "issue tracker" because it is clearer to most people.  I can say "Jira is an issue tracker" to my mother, and she gets it, but I can't tell her "it's a workflow engine" without explaining.

There is an obvious comparison with Trello - off-the-shelf, Trello really is a pure issue tracker.  You look at a card, you know where it is.  But there's no process or workflow in it, its just a pile of post-it notes stuck to a wall (which is often brilliant and all you need to get stuff done without forgetting bits).  Jira is a bit more formalised - your post-its have a defined lifecycle (and ownership, and notes, and and and)

This makes me rather confused though.  You say "how many organizations are using transitions vs no transitions"

The simple answer is "none".   Everyone using Jira uses transitions.  Just creating an issue is a transition.  Marking it done is a transition.  The most simple (useful) case has two transitions - "create" and "close".

So my confusion is around what you think "no transitions" means.

[Rebecca Hylek]

Sorry, if my wording is confusing :).  Like you, I often use "Issue Tracker" and I understand the "transition" states of moving the issue forward.  Maybe this diagram will help.

A very simple workflow used by many of my teams in the past was:

At my current organization, there are no transition steps.  I hope that clarifies, I'm certainly not asking for anyone to over think this, I was simply curious.

[Nic Brough -Adaptavist-]

That helps, it shows us what you have, but I don't see how you have "no transitions".

Both diagrams show transitions.

[Rebecca Hylek]

It's the same workflow, I showed the text and diagram for reference.  That's one from my past.

If the workflow were in my organization today, it would simply say "All" after each status, similar to this.  (Note, this is not meant to be the same workflow, it's just an example)

From what others are saying, they commonly use "All".

Thank you!

[Nic Brough -Adaptavist-]

Ok, so not "no transitions", just starting simple with a full set of "all" transitions.

You should add transitions (replacing all) when you have a process that is constrained.  For example, the original Jira workflow was a map of a process that Mike and Scott wanted to follow.

Broadly, it is Open -> in-progress -> Resolved -> Closed -> Reopened-> Resolved, with some other "go back one step" transitions. 

"all" transitions won't work in their process, because you never want to let an issue go back to "open".  If it needs more attention, it should go to re-open.  

I completely agree with Jack here - a workflow built of "all" transitions by default is a good starting point.   If you have a constrained process where you don't want to let people make mistakes, or it turns out people are abusing the "all"s, then you start defining transitions for them.

You may also want to control or execute different things in your workflow, and you should be using dedicated transitions when that happens.

An example I've set up recently - effectively an approval of sorts - an issue needs to go from "open" to "approved".   When Alice does it, we want a line of text written to a file on the server,   When Bob or Charlie do it, we don't.  We set up two transitions from open to approved, one with a condition "only Alice can do it" and the other with "only Bob or Charlie can do this", and Alice's transition has a post-function that writes to the file.

[Jack Brickey · Accepted solution]

Hi Rebecca,

by "no transitions" do you mean using the "All" transition where a user can transition an issue to a status fro any other status? Assuming so I would say that I generally use All anywhere that there are no conditions/restrictions/validation required. That is leave it open unless the process dictates.

if I am off the mark please help me better understand.

[Rebecca Hylek]

Yes, that's exactly what I meant.  Almost all have the "All" transition state.

As mentioned, in my past we used transitions for almost everything and it was well received this seemed different and in my opinion could lead to errors, i.e. epics closing or cancelling before all work is complete.

We're meeting later this week to discuss options so I appreciate your thoughts, thank you!

[Jack Brickey]

All is, IMO, a great place to start. You can always add complexities as needed down the road. Too often I have seen folks start with complex workflow transitions only to later regret it.

[Rebecca Hylek]

Thank you Jack!