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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


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
Community Members
Community Events
Community Groups

Remove sprint from Release Burndown Chart?

Hi folks,

I have an issue with a rogue sprint that made it into my release burndown chart but it shouldn't be there. Is there any way to exclude a sprint? What drives the sprints that are included here?

A bit about our jira config, We are using on Jira project for a number of mobile app and tablet related changes- this our product backlog. I use a custom field to create different boards based on change request ID, so the different pods only see the work that's relevant for their team. The other team's sprints are not populating on my release burndown as their stories are not included in the release (fix version) that my team are working towards. It's just the one stray sprint (CA Sprint 8) that somehow made it in and I can't seem to figure out why.


Any suggestions much appreciated!






2 answers

1 accepted

0 votes
Answer accepted

I found a solution in case anyone else is in the same shoes.

I rogue sprint was in this release burndown because a story from this release was added to that sprint (by error). 

  1.  I need to remove this story from the sprint so the sprint is no longer linked to the release. 
  2. As the sprint is closed, I need to reopen the sprint (not possible to remove sprint value otherwise)
  3. Once I reopened the sprint I can remove the erroneous sprint value from the my user story.
  4. This should fix the release burndown and you'll see this sprint is now not populating on the release burndown or sprint reports.
  5. Don't forget to close the reopened sprint.



0 votes

What drives the sprints that are included here?

Typically you will get rogue sprints, when the scrum board filter of your team shares issues with a scrum board filter of an other team, e.g. when you have overlapping filters or work on the same release.

  • Check the issues on the rogue sprint. 
  • Check the owner of the rogue sprint.
  • Make sure no other team includes your issues (unless it is wanted and multiple teams work on the same release)

Hi Leonard, 

Thank you for your answer.

The driver of the sprints should be the release ie the fix version, in this case Overdrafts phase 1. One of the stories from this fix version was accidentally pulled into a sprint by another team (not sure how this happened). My worry is that on the release burndown,  the metrics of this rogue sprint show as: 312 at start of sprint, 51 added to version, 78 completed and 285 remaining - but if I open the rogue sprint, CA sprint 8, it contains only one issue, the one from my fix version. I'm just trying to understand if I should exclude these figures from my calculation or are the figures correct (ie this is what actually happened in that fix version, during that time period)? What are the 78 story points that burnt down? Is there a way to open the issues that are included in this calculation (when I click on the bars on the release version)?

Sorry for the convoluted question, trying to make sense of it all.


Suggest an answer

Log in or Sign up to answer

Atlassian Community Events