nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How can I block the creation of an issue if the sum of story points in the sprint is too big?

Tir Neo

Hi guys,

I'm trying to do small but important thing for my team.
ENV:
Jira Cloud
Project - Company managed
Script runner

Problem to solve:

I need to block the possibility of creating a new issue with an assigned sprint if the sum of story points in the sprint exceeds X. Both sprint and story points are required for every issue.
I tried to achieve this using a workflow validator with Script Runner, but unfortunately, Script Runner in this case only allows me to use "Script Validators ONLY use Jira Expressions"
Is there any solution to achieve this?

edit.

I've implemented some similar using automation, but it only triggers after the issue has been created and it's too late.

Accepted answers

All comments

Pramodh M

Hello @Tir Neo

Welcome to the Community!

You can use a Jira Expression in a Script Validator with ScriptRunner. While this approach has some limitations, it can solve your problem. Here's how you can implement it:

Jira Expression for Sprint Story Point Validation

You can use the following Jira Expression in a Script Validator:

let sprintId = issue.sprint ? issue.sprint.id : null;
let storyPoints = issue.storyPoints ? issue.storyPoints : 0;
let maxPoints = 100; // Set your desired maximum story points here

if (sprintId) {
let sprintIssues = issues.filter(i => i.sprint && i.sprint.id == sprintId);
let totalPoints = sprintIssues.map(i => i.storyPoints ? i.storyPoints : 0).reduce((sum, points) => sum + points, 0);

if (totalPoints + storyPoints > maxPoints) {
return false;
}
}

return true;

This expression does the following:

Retrieves the sprint ID and story points of the current issue.
Sets a maximum story point limit (adjust maxPoints as needed).
If a sprint is assigned, it filters all issues in that sprint.
Calculates the total story points in the sprint.
Check if adding the new issue's story points would exceed the limit.
Returns false if the limit is exceeded, blocking the issue creation.

Implementation Steps

In your Jira Cloud instance, go to Project Settings > Workflows.
Edit the workflow used for issue creation.
Add a new validator to the creation transition.
Choose "ScriptRunner Script" as the validator type.
Paste the Jira Expression into the script field.
Set an appropriate error message, such as "Sprint story point limit exceeded.

Let me know how it goes!

Thanks

Dick

Hi @Tir Neo , Welcome to the Atlassian Community.

The answer to your question is quite simple and does not concern Jira. The team is in charge on how many story points they can manage in a sprint. It is the only way in which they can fully commit to getting the sprint done in its entirety.

Only by letting them do the full scrum circle of

sprint planning
daily scrum
sprint review
sprint retrospective

they can evolve into a better, more agile version of themselves and have focus on quality and efficiency.

Sprint planning is about which issues from the top of the backlog are we (as a team) comfortable with to fit into the coming sprint. When can we fully agree upon the fact that we're confident and committed to finishing the tasks we put into the next sprint.

Daily Scrum is about signaling potential setbacks and solve these in the safe environment of the team.

Sprint review is about letting the client / customer / stakeholder know the new stuff that's been developed in the last sprint. It provides the client to give feedback and even allows them to re-prioritize the order in which parts should be handled, and/or the direction into which the next sprint should focus. This gives the team the opportunity to (switch to (=agile!)) work on the stuff that's contributing the most to the clients needs.

Sprint retrospective is about the team learning and evaluating the last sprint, in order to increase quality and effectiveness of the incremental value they deliver to the client. Scope changes by tickets created and put in the sprint should be discussed thoroughly here, especially if they are the cause that a sprint goal isn't reached at the end of a sprint.

You can do many things in Jira to limit the creation of the mentioned ticket, but you cannot have this as an alternative to guarantee sprint completion. Furthermore, it would take away possible lessons learned by the team and would not contribute to team growth and welfare.

Kind regards,

Dick

Tir Neo

Thanks for your answer! We already all know about it but we just need something like this to another purpose.

Tir Neo

Unfortunately it doesn't work, i got the error

"Jira expression failed to parse: line 12, column 1: else expected, } encountered."

After some fiexes I got same error as when i'm trying to do it myself - "Evaluation failed: "issues" - identifier not available in context"

Tir Neo

Taking it from sprint it's not a must have, it's also can be epic

Dick

That's.... dare I say it... even worse.

Epics normally span multiple sprints. Plopping one of those into a sprint would have an enormous impact on team morale and sense of being in control of the sprint content.

A good read on the agile manifesto might steer you into the right direction here:

https://www.scrum.org/resources

Kind regards,

Dick

Dick

Whatever purpose you strive for, unwanted creation of tickets (of all types) in a sprint can be easily mitigated by putting restrictions on who can transition issues, found in the permission scheme of the project at hand, or specifically set in the project's workflow from status "open" into another workflow status.

There is no need for scripting if you enable this for a person that cares for team sanity.

Kind regards,

Dick

Bill Sheboy

Hi @Tir Neo -- Welcome to the Atlassian Community!

Adding to the ideas from @Dick ...

What problem are you trying to solve? That is, "why do this?" Knowing that may help the community to offer other alternatives, and for your team to discuss root causes and decide how to improve.

Until we know that problem being solved...

Attempting to automate the blocking of issue creation (or even assignment of issues to a sprint) may lead to unintended consequences...making the situation much worse. Those could include:

hiding work: people work on things not tracked in Jira, diluting team focus, and reducing collaboration and delivery predictability
reducing work forecasts by entering smaller values for sizing: this reduces learning about work sizes, delivery predictability, and understanding of why the team is using relative sizing
blocks actual exceptions: when something needs to come into a Sprint immediately, halting current work, a workaround may be needed to bypass any automated restrictions
creates unnecessary work / reporting: as Dick describes, there are already practices in the Scrum Framework to address capacity and planning needs
...

Kind regards,
Bill

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

scriptrunner

jira

cloud

jira-cloud

workflow

validator