Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Doubts in Release Burndown report

Aishwarya Chandrakumar
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 7, 2023

In the Release burndown report, there are stories planned for a sprint which was imported before starting the sprint using 'Start Sprint' options.However, part of the count in the bar graph is reflecting under 'Work added' (Scope change). I tried analysing and came to the below conclusion

1. Stories get reflected under 'work added' based on the time it was imported. If this is after the planned time of the created sprint, then it comes under 'Work added'

2.If the issue is reopened in same sprint

3.If the issue is split and one part is marked as completed in the sprint in execution and the remaining to the next sprint

This was all I could think of. However there are still mismatches in the counts which I am unable to figure out.

Are there any other scenarios that Jira considers under Work added? If someone moves the story to in progress and then later I start sprint, where do they get reflected.

Please help.

2 answers

0 votes
Yuri Lapin _Release Management_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 19, 2023

Hi @Aishwarya Chandrakumar

Trust you are well.

That's why I personally prefer burn-ups as opposed to burn-downs for Releases. If the scope of your sprints is stable burndowns are good. If not or you want to see the progress for release (assuming couple of sprints that automatically increases the likelihood of scope to change a lot) .. I bet, burnups is better.

Thus you can see the trend of adding scope and the trend of completing work .. and hopefully they intersect in the future;)

If you up to Partner Apps you might looks into our Release Burn-up and Trends Gadgets.

Cheers,

Yuri.

0 votes
Clark Everson
Community Champion
August 7, 2023

Hi @Aishwarya Chandrakumar 

Welcome to community!

Honestly for the issue of importing that would only happen if they had the sprint value in them

For splitting issues you should do that after you close the sprint before you start the next one.

For situations that impact scope:

  1. Work Added:

    • New Issues Added to the Sprint: If any new issues (stories, tasks, bugs, etc.) are added to the sprint after it has started, Jira considers this as work added.
    • Estimate Increases: If the original estimate of an issue is increased during the sprint, it's considered as additional work. For instance, if a task was initially estimated to take 2 hours and is later revised to 4 hours, Jira sees this as 2 hours of work added.
  2. Changing Scope:

    • Issues Removed from the Sprint: If any issues are removed from the sprint after it has started, this is considered a reduction in scope. The burndown chart will reflect this change.
    • Estimate Decreases: If the original estimate of an issue is decreased during the sprint, it's considered a reduction in scope. For example, if a task initially estimated at 4 hours is later revised to 2 hours, Jira interprets this as a reduction of 2 hours in the scope.
    • Issues Moved to a Future Sprint: If an issue is moved from the current sprint to a future sprint, it's considered a change in scope for the current sprint.

      Best,
      Clark

Suggest an answer

Log in or Sign up to answer