Automation to stop "start sprint" action if field conditions are not met

Question

Note: My org does not have ScriptRunner and no funding for other apps.

Hello,
My org's leadership wants to enforce a policy via Jira global automation or workflow.

The Policy:
All stories and tasks must have a parent and story points prior to starting a sprint. So, essentially the Start sprint action would fail if any story or task in the sprint does not have a value. For story points the value must be > zero.

The Ask:

We have the global automation to enforce the policy for any sprint. However, the teammates are not happy. Leadership has asked us to try to narrow the policy to validate all stories and tasks have story points and a parent only when users try to START a sprint. Does anyone in this amazing Community know how this can be accomplished? Is there a smart value for "start sprint"?

Thanks Community!

Walter Buggenhout · Answer

Ow ... small disclaimer: the above solution requires you to work in company managed projects with centrally managed workflows. These are essential for adding screens and workflow validators as I described into your workflow and work with multiple boards for the same project.

Walter Buggenhout · Answer

Hi @Apryl Harris,

There is no way you can abort the Start Sprint action after you hit the start button. It does not do much more than updating the sprint's status behind the scenes and making sure that the work inside your sprint now appears on the current sprint view.

What you are actually trying to do, is making sure that the items in your sprint backlog meet certain criteria. Most importantly: have a parent and a story point estimate. This is very much your definition of ready for items to go into the sprint backlog.

You should be able to design this through your story workflow. Make sure that you have a status ready for development in there that issues need to get to after prior analysis or preparation. Add a transition screen in your workflow where you add the parent and story point fields and use a workflow validator to ensure that both fields are required before you allow the issues to move into the ready for development status. This would allow you to fulfil your Definition of Ready requirement.

Make sure to map the ready for development status to the backlog of your scrumboard. Create a second board that only has the statuses mapped that precede and lead up to the ready for development status in your workflow. That board allows your analysts to keep an overview of the preparing work.

Hope this helps!