Forum Discussion

nickkrit's avatar
nickkrit
Visitor
3 years ago
Solved

Burn Down Chart Dashboard gadget does not display accurate burn down

When building a Dashboard containing Burn Up and Burn Down charts using the SmartBear Zephyr Scale gadgets in Jira Cloud, the results displayed in the Burn Down chart are simply a mirror-image of the results displayed in the Burn Up chart, not accurately displaying the Execution Remaining results as expected.

 

Configuration:

 

Results:

 

Using identical configuration specs, the Burn Up chart shows we tested 21 Test Executions (of 771 total) on June 09, 2021.  The corresponding Burn Down chart does not represent that on June 09, 2021 we should have 750 Test Executions remaining.

 

Is anyone else seeing these type of results from these gadgets?

We are trying to build dashboards for management to be able to track real-time results, but the gadgets don't appear to calculate the data correctly.

  • Hi nickkrit ,

     

    yeah, you're right. I actually created a bug report for this back in early 2019. Let me quote the reply I got from the support team.

     

    "

    As it turns out, the burndown and up charts as of now, use the date of the earliest execution as start date and the date of the latest execution of the final date and them on top of that it plots the chart it is plain wrong, so we are aware and we have addressed to get this fixed in the near future, also there are some known bugs in these charts, so eventually when you compare them they do not match correctly.

    As soon as we get it fixed, we will get back to you.

    "

     

    The ticket still sits in the Awaiting Development status.

    We have actually told all our users to not use these reports (burn up/down) since they simply do not work as expected.

     

    Cheers

    Josh

3 Replies

  • josh42's avatar
    josh42
    Community Hero

    Hi nickkrit ,

     

    yeah, you're right. I actually created a bug report for this back in early 2019. Let me quote the reply I got from the support team.

     

    "

    As it turns out, the burndown and up charts as of now, use the date of the earliest execution as start date and the date of the latest execution of the final date and them on top of that it plots the chart it is plain wrong, so we are aware and we have addressed to get this fixed in the near future, also there are some known bugs in these charts, so eventually when you compare them they do not match correctly.

    As soon as we get it fixed, we will get back to you.

    "

     

    The ticket still sits in the Awaiting Development status.

    We have actually told all our users to not use these reports (burn up/down) since they simply do not work as expected.

     

    Cheers

    Josh

  • MisterB's avatar
    MisterB
    Champion Level 3

    As Josh says, this is an issue.  The fact that the report starts only when a test case is executed throws renders the data useless and in the end, I used the data set export option (visible in reports like Test Execution Results List) and built my own burn up charts in Excel.

     

    I see that what you really want though is real-time reporting so another option open to you is to use the APIs to connect to a tool like Excel or Power BI, and build your charts in there. If you want to explore that route you'll be using APIs and JSON data sets.

     

    Cheers, Andy

  • Smithjoara's avatar
    Smithjoara
    New Contributor

    I have submitted several tickets in the past regarding problems with the Agile Burndown Chart not reflecting the work remaining in the sprint (eg. GHS-9079  and GHS-6788 ). There should at least be an option so that value on the (red) burndown line will balance to the sum total of the "Remaining Estimate" on each ticket in the sprint. Subtracting the time logged from original estimate may have some value but it certainly does not give an understanding if the work can be completed in time for a pending release date or how much time will be carried forward to a following sprint. Remaining estimates are often increased once work has started and you do not want to also increase the Original Estimate otherwise you cannot provide guidance on estimate accuracy for future sprints.

    funko pop danmark