- edited description
Release Burndown shows incorrect Current Scope
Hi
I am having a rather fundamental issue with the Release Burnup Burndown Chart so my apologies if I have simply missed something obvious. Issue is as follows:
My JQL filter returns items where the sum of the story points is 32
but my Release Burnup Burndown Chart shows a Current Scope of 78
See notes below. Any reason you can see that it shows the incorrect figure?
Thanks
Darragh
Notes
Based on https://bitbucket.org/StonikByte/great-gadgets-add-on/issues/20/amount-of-done-issues-differs-from-jql I have tried manipulating the dates so the range is very broad. All items were created in 2019 - date range I am using is 09/07/2018 to 30/06/2020.
I am summing the Story Points field where issuetype=EPIC (Should not make a difference in my opinion but worth noting)
Does it match exactly on “Story Points” field or is there some possibility of like %? (There are other similarly named fields)
This is a project that we started early 2019, paused and then picked back up (I can see this way of working would throw out trend related fields but not for Current Scope)
We are using Jira DC (Jira 7.10.2) but our Great Gadgets plugin/license is server
Jira Filter:
Config of gadget
Version Details
Installed version:1.6.0 (Not available as an option int eh drop down in support portal)
Available version:1.7.0
Vendor:StonikByte
Support:Supported by vendor
App key:com.stonikbyte.great.gadgets.server
License details:500-user commercial license, Standard, expires 17/Oct/19
License status:Valid
Comments (8)
-
reporter -
reporter - edited description
-
reporter - marked as minor
-
repo owner - changed version to 1.6.0
-
repo owner -
assigned issue to
-
assigned issue to
-
repo owner Hi @Darragh Gammell ,
Thanks for posting.
There are various possible causes for such issue. We need to take them one by one and investigate.
First, we have to check if the story points field is unique in your Jira instance. The add-on does an exact match (not a Like %) in order to identify the field, but we had cases when some customers had a duplicated "Story Points" field in their Jira database.
Please run this URL in your browser and copy-paste the data returned in a text file and then send it to us:
<Your Jira base URL>/rest/api/2/fieldThen, we need to compare the list of issues returned by your JIRA filter with the list of issues returned by the filter's app and compare them.
Please run this JQL in your Jira search screen:
filter='CAP - All items including EPICs' AND issuetype IN standardIssueTypes()
Export the results as CSV/Excel with the following fields: Key, Date Created, Date Updated, Status, Story Points and send it to us.Then please install this new JAR https://bitbucket.org/StonikByte/great-gadgets-add-on/downloads/great-gadgets-server-plugin-1.7.0-SUP957.jar - it is a modified 1.7.0 version that comes with more logging that we need about the issues included in the scope calculation. It's safe to use in production. Go to Jira Administration > Add-ons > Manage add-ons and click “Upload add-on“ and provide the downloaded JAR.
After installing the new JAR, go to Jira Administration > System > Logging and Profiling. Then click "Configure logging level for another package" and add the following:
Package: com.stonikbyte.great.gadgets.common.tasks.TaskGetReleaseChartData
Logging Level: INFORefresh the gadget and open the atlassian-jira.log. We need all the lines that occurs after the one that contains "##Release Burndown Chart".
For privacy reasons, we recommend sending all the info that you collected to support@stonikbyte.com instead of posting it here.
Looking forward for your reply.
Thank you,
Danut Manda -
repo owner After investigation we found out that the issue was caused by the fact that the Story Points field value was set by a custom script made in ScriptRunner. This script updates the field directly and does not log the change in issue change-log (history). Our Great Gadgets app, by design, uses the issue change-log to determine the issue status and estimate along the time and because there were not change log entries it resulted in showing wrong data.
A solution in this case would be to modify the ScriptRunner script to update the Story Points fields using Jira REST API, which takes care to update the issue change-log as well.
-
repo owner - changed status to resolved
- Log in to comment