Release Burndown shows incorrect Current Scope

Issue #41 resolved
Darragh Gammell created an issue

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)

  1. Danut M [StonikByte] 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/field

    Then, 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: INFO

    Refresh 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

  2. Danut M [StonikByte] 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.

  3. Log in to comment