Using "When: Sprint completed" automation fails

[DjBricheta]

Hi guys,

I am trying to do an automation that will transition all the open issues (to do, in progress, etc.) to the next sprint when the current one is completed.
I tried to configure some rules but I get the following error:

The rule has been configured with components that require issues to be provided by the trigger. To run these components you must add a branch for this sprint or JQL. The following components require issues: Transition issue

Here is how the configuration is made right now:

I'm testing it on Jira v8.4.2, but the rule needs to be used on v7.8.1. (not sure if it makes a difference or not)

Can you help me figure this out?

Thank you,

Andrei

[Ste Wright · Accepted solution]

Hi @DjBricheta 

Just to ask - why do you need this automation rule?

When you complete a sprint, it should ask if you want to move the issues to the backlog, another sprint or a new sprint. This is on the current version, worth checking if it is an option on v.7.8.1

I built an example rule to test this - but that option overrode my automation!

This might disregard the need for the automation rule - or are you trying to achieve something else with it?

Ste

[DjBricheta]

Hi Stephen,

I didn't know that this is a default feature of Jira, my bad.

I think I would still need to have some automation, because some of the statuses we use to mark the issues as complete will actually be a sub-status of in-progress, so they would not work properly.

But probably the easiest way would be to modify the statuses to be sub-statuses of done.

Thanks for the help!

[Ste Wright]

Hi @DjBricheta 

Not quite sure what you mean by sub-statuses - but sprint completion basis "done" on what statuses are in the last column on the active sprint board, as opposed to workflow status order. So you could put all statuses which class as "sprint done" into the last column :)

I did try to create the rule - but it seems like the board option of what to do with issues after sprint completion overrode the automation rule's action if it differed.

The rule I tried was:

• Trigger: Sprint Completed = Board
• Branch: Using "JQL" as type of related issue, I searched for sprint in opensprints()
• Condition: Issue Fields Condition - Set field to "Status", condition to "is not one of" and in value, added all statuses in the last column of our board
• Action: Edit Issues - Set "Sprint" to "Next Sprint (Board Name)"

Ste

[DjBricheta]

Hi @Ste Wright 

I didn't have all the information needed for this automation, so my question is not entirely complete.
I have the following statuses:
To Do (Blue)
In Progress (Yellow)
Developed (Yellow)
Deployed to test (Yellow)
Done (Green)

When a user story is complete, it will be in the Developed column, so when are the stories are complete, the sprint can be completed.

Now, what I want to do is, once a sprint is completed, all the stories from 'To Do' and 'In Progress' to be moved to the next sprint, having the same statuses; and all the stories from 'Developed' to be moved on the next sprint, on the 'Deployed to test' status.

After you said that the default automation overrides the custom one I was thinking that maybe the best way to do this is to use the default automation, so all the issues will be moved to the next sprint, on the same statuses.
And in order to achieve the status transition, to create a 'When Sprint started' automation, which will transition all the issues from 'Developed' to 'Deployed to test'. Do you think this will work as expected?

P.S.: I don't manage to understand how to do this 

Using "JQL" as type of related issue, I searched for sprint in opensprints()

Thanks for all the help until now,

Andrei

[Ste Wright]

Hi @DjBricheta 

For the automation rule, you can do it either way - so the rule would be:

1. Trigger: Sprint Started OR Sprint Completed = Board
2. Add a Branch. On the branch, change "Type of related issues" to JQL - then enter the JQL: status = Developed
3. Action: Transition Issue - with the destination status of "Deployed to Test"

---------------------

I would be careful with this approach however.

Using this process, you won't get the full value of working in sprints - as the reporting - such as burn-down, burn-up or velocity chart - works off completion within a sprint, which is classed as the statuses in the right-most column.

If Testing and Development cannot be done in one sprint - or is completed by different teams - I would consider whether you need:

• Two Scrum Teams / Boards: To track the separate sprint goals of the different teams. The end column for developers would be "Developed"
• Separate Issues: Potentially splitting these into separate issues - for example, Story and Test - and tracing them across modified workflows. This could mean Developed is a "Done" status - or each workflow utilises resolutions to show the difference (Story has resolution "Developed", Test has resolution "Done")
• Kanban Board: Whether a board without a sprint would be useful for Testing / Deployment.

---------------------

Let us know if this works for you!

Ste

[DjBricheta]

Hi @Ste Wright 

Thanks a lot for helping me with the automation. I will test it Monday morning when the Sprint completes and I will come back with some updates.
--------------
As for the approach, I know that this is not a good one, and it's definitely not a final way of working. It's just how the setup is right now for the first (and probably second) sprint.

At first I was thinking of having an active sprint at all times, which will get the Developed Issues when their sprint completes, so we can actually have some accurate charts.

But after reading your answer I'm thinking of having 2 boards, as you said, so when a sprint is completed in the Dev board, all the issues will move to the other board, to track their deployment&testing status.
I would not want to split the issue into Story and Test, because I want to be as easy as possible to follow the history of an Issue.

If you have any ideas, I'm more than open to hear them. (even though this is probably not the best place for them, not being related to the question, haha)

Have a great weekend!
Andrei

[Ste Wright]

Hi @DjBricheta 

No worries :)

That's fair on wanting to see the full lifecycle of an issue - that would be my preferred approach.

Have a great weekend also! Let me know if it works on Monday!

Ste

[DjBricheta]

Hi @Ste Wright 

Tried to do a second board (Test), and that automation, but it doesn't work as planned, unfortunately.
The automation is set to change the status of the 'Developed' issues once a sprint is completed and also to set the active sprint of the Test board as the sprint field, for every issue that is in 'Developed'

The problem is that it moves the issue, but instead of putting it to the active sprint, it puts it into the backlog of the Test board.

What I also saw is that, when I complete a certain sprint, on the first board, the active sprint from the Test board changes too
(e.g. I complete sprint 6 in first board -> Test board's active sprint becomes 'Board Sprint 7' from 'Board Sprint 6')

Probably this is the reason why the automation doesn't work as planned, but I'm not sure how to fix it.

Thank you,

Andrei

[Ste Wright]

Hi @DjBricheta 

Just to confirm:

• At closure on Board 1, the automation sets the status of "Developed" issues to "Deployed to Test" and attempts to put these into the current/next sprint in Board 2 - but instead it puts them into the Backlog
• When completing the sprint in Board 1 (manually?) it also completes the sprint in Board 2

Is this what is happening?

Ste

[DjBricheta]

Hi @Ste Wright 

Yes, that's exactly what's happening. (#2 - yes, manually)

Andrei

[DjBricheta]

Hi @Ste Wright 

Do you have any idea about this, or how to fix it?
I figured out that sprints are linked because it's one project and two boards, but I can't figure out why the automation doesn't work

Andrei