How can I edit the Burndown Report to only show relative decrease in storypoints and not net change

[Deleted user]

Hi Everyone, 

I want to edit the Burndown Report of our app to only show (visually graph) the relative decrease in story-points and not the net change (increase || decrease) relative to the total number at the start of the sprint. 

[ SPECIFIC EXAMPLE ]: 

- we have a sprint planning session and come up with 100 story-points for the sprint 

- during the sprint, we end up having to complete additional tasks (not included in initial sprint planning session / story-point assignment) -- out total is now 105

- to track and reflect the work completed, we create a new parent / child tasks with additional story-points -- we add 5 child issues each with 1 story-point

- we then immediately close each child task and update the parent story point estimate

[ ISSUE ]: 

- when we view the burn-down report, it shows that we increased the total number of story points (100 --> 105) and then immediately reduced the total number by the same amount (105 --> 100)

[ TO BE RESOLVED ]: 

- is there a way to have the graph simply shift vertically (to reflect the increase in total number of story-points to be completed in the sprint) BUT have the graph only reflect the decrease (after tasks are closed and story-points are removed). 

- We would like the y-axis to scale as a result of adding story-points AFTER the sprint start date and have the graph then only reflect a net decrease in story-points. We want the actual line of the graph to only ever trend towards zero while the y-axis should be shifting upwards as points are added even after the sprint start date 

[ ALTERNATIVE ]:
- is there a way to edit the original number of story-points from the  initial sprint-planning session?


THANK-YOU

[Bill Sheboy]

Hi @[deleted]  -- Welcome to the Atlassian Community!

The short answer is: no, not with the built-in functions and reporting of Jira cloud.

There are some marketplace add-on tools which provide burn charts that more accurately reflect what happened, from sprint planning to sprint completed.  Alternatively you could repeatedly export the issue data during the sprint, or call the REST API to access the logs, and then build your own burn charts.

Best regards,

Bill

[Deleted user]

Thank-you for taking the time to shed some light in this for me, I appreciate the help Bill! We will have to find another solution in that case :)