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:
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!
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:
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
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哥
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It seems we cannot use that conditon of the JQL statement "Sprint IN openSprints()".
I'm just thinking out a solution to your requirement:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.