JQL for story points change mid sprint

[Manish Nadar]

Hi All,

Once sprint has started, i would like to track Story point change via JQL to add on dashboard.

If acceptance criteria is changed mid sprint then SP should also be reviewed which is the purpose of the ask.

Is this possible?

[Mark Nesbit]

I now do a daily CSV export and using some excel filters track SP's and issues during sprints.

[Manish Nadar]

So JQL does not support tracking Story point change in a active sprint?

[Mark Nesbit]

I have done some digging and research and as yet I have not managed to find a solution.  In the end for the sake of setting some queries and exporting them (5 mins) in the morning, I can take a snapshot of the sprint (day by day).  This is quite a low tech solution for now but it does mean I can gather meaningful data for sprint reports with more granular data.

[Manish Nadar]

Ok thanks Mark.

[Stephen_Lugton]

Hi @Manish Nadar 

For a quick view you can go to Reports > Sprint Report and you can see any story point changes there:

You could also use automation to track story point changes e.g. by adding a comment:

This could be expanded to send a slack message, or an email for example

[Manish Nadar]

Thank you Stephen for your response.

I wasn't aware of the automation option.

So JQL does not supports tracking of SP change correct?

[Stephen_Lugton]

@Manish Nadar there are a few fields that can be searched in JQL based on when they changed but this is for Assignee, Fix Version, Priority, Reporter, Resolution, and Status fields only.

Apart from those, JQL only shows the current state of a field.

For story points we're normally only using the number of points as of now, although through smart values in automation you can see the before and after value when a field changes.

And if you want to use automation you'll need to have admin permissions.

[Manish Nadar]

Ok thank you. Appreciate the insights being shared.

[chad_leblanc]

Yeah Stephen nailed it - for something like this, Automation would be the best route to go

[Bill Sheboy]

Hi @Manish Nadar 

Please consider pausing and discussing with the entire Scrum Team (product owner, delivery team, and scrum master) to better understand why this is happening, perhaps at your next retrospective.  And consider the consequences of changing the work items after the sprint start on achieving goals, planning work, code quality, morale, etc.

You describe someone is changing the acceptance criteria and sizing (i.e., story points) for the work items after the sprint has started.  Those are symptoms of a root cause, such as challenges with backlog refinement, sprint planning, product owner / team focus, etc.  Understanding the cause will help decide how to address that cause...rather than just detecting the symptoms.

Although monitoring may seem helpful, without fixing the cause this behavior may become normal to the team, reducing the chances it will be corrected.  Hopefully this is an infrequent event and so reduces the need for building reporting around it.

Kind regards,
Bill