Incrementing Based on Current Sprint Status

[Alex Young]

Hey community, I could use some assistance with an automation. Here is a story for a feature:

As the product manager for a Scrum team, I would like to see a running count of the number of times that an issue is rescheduled from an active sprint into another sprint, this will allow me to analyze the average number of times different issue types are are carried over from sprint to sprint because they didn't get done.

The point is to provide insight on how accurate our sprints tend to be by automatically collecting the number of times an issue is rescheduled.

I have developed a rule which I thought would work:

1. WHEN the field value changes for the Sprint field
2. IF the issue falls into one of our selected issue types
3. AND IF the issue matches the JQL statement "Sprint IN openSprints()"
4. THEN increase the field value of the Open Sprint Reschedule Count field by 1

Here is a screenshot of the rule as it current stands:

Expected behavior: The rule would validate that the issue falls into one of the issue types AND that the issue's current sprint is an active sprint and it moves into a different sprint or the backlog (line 3).

Actual behavior: The rule only triggers when an issue is moved INTO the active sprint, moving it out of the active does not result in the rule firing.

Am I misunderstanding how the JQL condition component works? Is there a way to check the current value of the sprint field? Am I overlooking something obvious?

Thanks in advance!

[Bill Sheboy]

Hi @Alex Young 

First things first: incomplete work carrying over after a sprint finishes is a symptom, hopefully leading to team discussion and improvement experimentation.  As things improve, measuring any carryover could be halted as the measure is no longer needed / relevant.

Back to your question...

Measuring the "# active sprints for this issue to complete" is a tricky thing with Jira...because the changelog for the Sprint field has some challenges (i.e., defects).  Thus it is not straightforward to just count these iterations.  Plus, the sprint field can be tampered with, altering the history upon which such counting happens.

One way to address these limitations is managing your own markers to help count:

• mark issues in some way when...
  • they are in a sprint when it starts, or
  • they are added to an in-progress sprint
• increment an issue's counter when...
  • they are removed from an in-progress sprint, or
  • the sprint completes and the issue is not done

The initial marking may be done with two automation rules, and I recommend using an entity property rather than labels, custom fields, etc. to reduce tampering or errors.

The counter increment may be done with two other rules, including a reset of the original marker so it helps to count the next, in-progress sprint.

Also please consider how to address "oops" errors for issues added / removed from sprints; that will help when trying to remove outliers from analysis of the measure.

Kind regards,
Bill

[YY Brother]

Hi @Alex Young 

Actual behavior:The rule only triggers when an issue is moved INTO the active sprint, moving it out of the active does not result in the rule firing.

I think this result makes sense. Let me give you an example:

When a sprint end date comes, but story A is not complted, we complete this sprint and story A is moved to Backlog or the next not-started sprint. Currently, there's no active sprint for Story A and only a closed sprint for it.

When we kickoff a new sprint with Story A, maybe timing is up for incrementing that count field.

BTW, the sprint status has three values: Future (not started), Active (during sprint) and Closed (complete sprint) as shown below:

Hope it helps.

Thanks,

YY哥

[YY Brother]

It seems we cannot use that conditon of the JQL statement "Sprint IN openSprints()".

I'm just thinking out a solution to your requirement: