Prevent tickets being added to sprint unless certain fields are set

[Gavin McMenemy]

I'm trying to figure out the best way to prevent tickets being added to a sprint unless certain criteria are met. 

For example: Description being empty, Component with no entries, missing story points...

Nagging and training (and rewards ...) haven't worked so now i'm looking at validation. 

If possible I'd like to also have a pop-up that tells people what is missing. But baby steps. I would just settle for a process that prevents a ticket being put into a sprint if it doesn't meet critiera. 

I can't see how to require certain information prior to being added to a sprint.

Yours... frustratedly... 

Note: I have since made Description a required field. However the other fields may not be known at time of creation (eg points) so while a ticket might be created without any points we need them before the ticket is added to a sprint. 

[Trudy Claspill]

Hello @Gavin McMenemy 

There is no native functionality to validate fields as an issue is added to a sprint and prevent the addition if the validation criteria is not met.

With native functionality the best you could do is set up an Automation Rule to detect that the Sprints field was updated with a value being added. Then in the rule add steps to see if the fields meet the requirements. If they don't, then add a step in the rule to remove the issue from the sprint. And maybe add a step to send a notification email to the initiator to let them know why the issue was removed from the sprint after they tried to add it.

[Gavin McMenemy]

Seems like a bit of a complex way of dealing with this. Obviously we do retros, 3 amigos etc. But needing to setup a rats nest automation rule seems a bit much. I wonder if anyone has come up with anything. I'll have another look around. 

[Joel Batac]

@Gavin McMenemy Did you find the solution? I made an automation similar to your requirement. 

[Gavin McMenemy]

Hi Joel, 
No I never figure that out. What does this do exactly? 

Looks interesting.

[Trudy Claspill]

That is an example of the rule I proposed.

With native functionality the best you could do is set up an Automation Rule to detect that the Sprints field was updated with a value being added. Then in the rule add steps to see if the fields meet the requirements. If they don't, then add a step in the rule to remove the issue from the sprint. And maybe add a step to send a notification email to the initiator to let them know why the issue was removed from the sprint after they tried to add it.

[Joel Batac]

@Gavin McMenemy it clears the sprint field thus moving it to backlog. So I think for you can be as below.

@Trudy Claspill - yep. Mine checks for Acceptance Criteria. If it is empty, it clears the Sprint field/moves the issue to backlog.

[Trudy Claspill]

@Joel Batac 

What if the field contains historic information about sprint the issue was added to previously, where the sprint completed but the issue remained incomplete? Does it remove those values too?

[Maciej Dudziak _Forgappify_]

Hi @Gavin McMenemy

You could potentially make fields required during transitions. In my last project, we had two statuses before 'In Progress.' New issues had a 'Triage' status, and once all the information was collected, the PO would transition them to 'Open.' The backlog was configured not to show 'Triage' issues, so it was not possible to add them to the sprint via the Board.

You could make similar adjustments and require fields during transitions. This approach worked for us.

Cheers

[Gavin McMenemy]

Hi @Maciej Dudziak _Forgappify_ 

That's interesting. One of the Devs has suggested a possible change around status transitions:

Open == Backlog
Selected for Development == In Sprint

And I confess I haven't explored this idea much. 

So how did you manage it? Did you set something up to prevent a ticket going into the sprint that didn't match a particular status? 

[Maciej Dudziak _Forgappify_]

Not really, there is nothing you can do to prevent users from editing sprint in the issue view. But, for us, it was sufficient that Triage issues were not visible on Board ( you can change jql filter for that). That prevented mistakes, and was good enough.