How do I use a transition based on a resolution?

[Jason Ried]

Hi everyone,

We have a board setup and this is working great but we need to take it a step further and add a new workflow which automatically assigns users working in a pipeline.

In short:

• Columns are: To Do, In Progress, Done, Closed
• Workflow needs to take an issue from To Do through In Progress and when complete the user places it back in To Do. When this happens the resolution gets set to "animated" and the assignee gets set to the next person.
• That person repeats the steps but the resolution gets set to "setup" and the assignee gets set to the next person.
• That person then repeats the steps but places it in Done where the resolution gets set to Done and the assignee is removed.

That way a single issue is added into the sprint and this allows all users to action the issue when they are supposed to. Going forward we might not ask the users to move to To Do, but set it so that if they move it to Done, then it automatically moves it to To Do with a new resolution etc.

So the question...how do I get this to happen? We can set the transition and have unique resolutions etc. but how do I add an IF condition to the transitions so that I can have multiple transitions which update the issue according to the resolution field?

[Nic Brough -Adaptavist- · Accepted solution]

I'm afraid this is a really bad design in JIRA terms.  You really do not want to use Resolution like this - it should never have a value when it's in a to-do or in-progress column.

It actually sounds like your workflow is wrong - it should represent the actual process that you want to follow, which looks to me like to-do -> person 1 animates it -> person 2 sets it up -> done.

[Ignacio Pulgar]

Agree! Just create new statuses, so that you can create this workflow (and columns in a board):

To Do > Animating > Configuring > Done

The Resolution field should be set just once, when everyone have finished doing what needs to be done.

Mind that JIRA considers as closed those issues that have a Resolution set, and that will affect the displayed data in many of its built-in tools/gadgets.

[Jason Ried]

I actually agree with everyone, though the problem we have is trying to not over complicate things with multiple boards. Having a simple clear board is better as the team is multi disciplined and growing, so we don't want them to see a lot of columns which bear no relation to them.

[Nic Brough -Adaptavist-]

Actually, this is a good case for multiple boards.  Remember that the boards are a view of a pile of issues, and hence configurable separately.  Rather than trying to build a terrible workflow that doesn't really match your process, just to get "one board", think about how to look at the process.

What I would do is:

• Create a workflow that broadly goes:  To do -> being animated -> waiting for setup -> Being set up -> done
• Create a Scrum board for planning.  Depending on how your teams interact, you might just have this with three columns (To do -> in progress -> done) but you might want to have all five (or more).  The main point here is to allow for clear planning of a sprint, and a glance at the three primary meta-states.
• Create a Kanban board for the Animators.  It should have to-do, being animated and animation complete (waiting for setup) columns.
• Create a Kanban board for the setup people.  It should have to-do (waiting for setup), being setup and done columns.

This gives you a good overview, and team-centric views

[Jason Ried]

Am I correct in saying that if we do this then these boards operate independently of each other? i.e. if the artist updates his kanban board then this doesn't update the spring board?

One of my concerns is that we don't segregate the team based on discipline, they actually work together as a mini team and so having different boards creates a sense of them being apart in tasks.

[Nic Brough -Adaptavist-]

No, the boards are all views of the same underlying data.  So a change in one board affects the others because their data changes.

It's not 100% dynamic, if that's what you're asking though.   If you have one person looking at a board and moving stuff around, and another person on another machine is looking at a board.  If person A moves an issue to a new column, it won't magically update the other person's board.  If person B refreshes, or tries to do something with an issue that is now invalid, they'll be told about the change and the board will be updated. But because the changes are all to the underlying data, it remains valid (Note that this applies even if it's the same board they are looking at).

One thing I tend to recommend with multiple boards is to share all of them with all the teams - although your artists may work entirely in the artist Kanban board, make sure that they have access to the main Scrum board and the setup Kanban, so that they can see what others can see if they need to.

[Jason Ried]

Awesome, that would really work then. It's not a major problem that it's not 100% live in terms of updating. Thanks yet again for the answer here!

[Nic Brough -Adaptavist-]

Ok.  Let's simplify this a bit to begin with - forget the board for artists - whatever is wrong there is likely to be similar to the programmers board, so let's fix that first.

So, some basic questions:

On the scrum board, what is the board filter, and what status do you have for the columns of "to do" and "programmers in progress"?

On the Programmers board, what is the board filter, and the sub-filter, and what status do you have in the "to do" and "in progress" columns?

[Jason Ried]

I realised very quickly after posting this that I had set up a scrum board which used a very similar project name to my test one. The problem was that I was referencing that one and not the test one where I had the issues :-0

Sorry about this, I thought I had deleted the comment before anyone noticed!

[Nic Brough -Adaptavist-]

Ooops   Oh well, glad it's fixed (or explainable anyway!)

[Seongmin Park]

How did you made this link? This is 🤩 awesome. 

[Nic Brough -Adaptavist-]

What link?

[Steven F Behnke]

I have my own take on this but I really agree with Nic and Ignacio. I try to break this down all the time for customers so, simply put: 

• Status is WHERE you are in the workflow.
• Resolution is WHY it is in a GreenCompleted (or green) status.

Mixing them will only cause headache. ALWAYS SET a resolution when you move to a green status. ALWAYS CLEAR the resolution when you leave a green status.