Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,710
Community Members
 
Community Events
176
Community Groups

How to freeze sprint burndown report when sprint is closed.

During sprint#6 retro, the scrum master walked through the previous five sprint reports. This showed significant improvement and got the team excited. A week later, when the same thing was shown to a broader group on how this team was performing, the previous five reports of closed sprints had changed dramatically.

  • What causes this? How do we prevent it from changing?

 

Screengrabs of the same closed sprints taken ten days apart.

Screenshot 2022-03-03 083403.jpgScreenshot 2022-03-03 084206.jpg

 

3 answers

Hi, @DSell

You may consider using some tool to see what is changing and when. "eazyBI for the Jira app" provides an option to look at Sprint scope changes based on issue change history and story point values at the moment when the sprint starts and ends.

For example, what was committed, what was added or removed later, which issues were done before sprint was closed, which issues were completed after the sprint, and maybe some issues changed the story point value. 

Here is the sprint balance report example for illustration: https://eazybi.com/accounts/1000/cubes/Issues/reports/168153-story-points-balance-by-sprints.

Best,
Zane / support@eazyBI.com

Great idea!  Thank you

@Nic Brough -Adaptavist-, Thank you for help your thoughts on this. Yes, I agree that items should not be worked on in a past sprint that they should be reconciled and moved to the backlog or another sprint. All points were well taken, and we continue to coach on that.

My thought is that, no matter what happened to those issues, it would be nice if at the point in time the sprint is closed that the report is frozen. This way, the teams have that history of how they performed in sprint01 and can see their improvement looking back from sprint06.

Thank you,

David

0 votes

This suggests people have been updating issues that were worked on during the sprint, changing what the sprint reports are reading from them

But shouldn't the report be frozen when the sprint is closed? How do you get a good picture of what happened in a closed sprint if changing the story later changes the closed sprint?

The report should be reporting on the data you have.

There is a very important point in your question here:

"what happened in a closed sprint if changing the story later changes the closed sprint?"

Why are you changing the data in a closed sprint?  The sprint is done, your open issues have moved on, your closed ones should not be changing.  Why are ended issues changing?

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events