Greenhopper sprint burndown rest api understanding

[Yuvam Jain]

Recently in one of my project i used Greenhopper sprint burndown rest api and outputs seems not correct.

For some issues, scope changed values are matching but not for others.

Is there any documentation available which describes on what basis i can define the scope change, issue added or removed etc.

[Andy Heinzer]

Hi Yuvam,

Sorry to hear there are problems here in regards to the burndown data from a Jira Software Server site.  We do have some information in regards to what that chart will do and look like in the documentation of Burndown Chart.  However this doesn't explain the REST API responses in regards to this chart.  You can find some data in regards to the Agile REST APIs for Jira Software/Agile in JIRA Agile REST API Reference - JIRA Agile 7.0.4.

But that said, there is a known bug in regards to issues being removed from a sprint.  Please see the bug report in JSWSERVER-14984 - Issue removed from Sprint not showing in Burndown Chart or Sprint Report. It explains that most of the current versions of Jira Software Server are suffering a bug that does not accurately display in the burndown chart when an issue is removed from a sprint.   I suspect that you might be seeing this bug, but please review the description there to confirm if this matches the problem you are seeing.

I hope this helps.  Please let me know if you have any followup concerns.

Andy

[Yuvam Jain]

Hi Andy,

Thank you for your response.

You are right when you mentioned the case where issue is removed from the sprint and not coming as correct in burndown rest api response.

I need help in following case:

1. Identify the logic to detect scope changes values in rest api response. Means, it is a story point increased or decreased.

2. What is story points for an issue is managed by some external plugin. Does rest api response capture such events.

Thanks in advance.


Regards,

Yuvam

[Andy Heinzer]

Hi Yuvam,

With the existence of that documented bug, it's not exactly a trivial task to identify scope changes via the REST API.  However, you could start by first using the endpoint GET /rest/agile/1.0/sprint/{sprintId} in order to get back the startDate value for the sprint itself.  That is key to understanding scope changes.  Any issues added to the sprint after the startDate, or had their estimates changed after the startDate will equate to a scope change.  What you could do would be to get all the issues in that sprint with GET /rest/agile/1.0/sprint/{sprintId}/issue 

However the rest/agile endpoints won't really be able to tell us which issues those are it seems with this bug in play.  You could then try to use the endpoint GET /rest/api/2/issue/{issueIdOrKey}  along with the parameter expand=changelog option to show all the changes in the individual issue's history.  That issue history will have dates and times of changes, such as being added to the sprint, or having an estimate changed.  You would also have to repeat that last issue call for each issue in the sprint to see what scope changes have happened.  BUT the big problem here is that since the 2nd rest call can only return to you issues that are currently in the sprint, you won't be able to see the issues removed from the sprint. Those are technically a scope change, but unless you know which issues they are, it isn't obvious how you can easily determine this from the REST API.

In regards to your second followup question, it's not clear to me.  I understand that plugins like Tempo or alike could be using their own estimates for issues outside of Jira's own fields.  In cases like this I don't expect that the Agile reports native to Jira Software/Agile will be able to access that data at all.  If that is the case here, then the steps I've posted above might not be of any use to you here.  But I hope this helps to clarify.

Andy