It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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!

Thanks,

Reka

releaseburndown.png

 

 

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.

Thanks,

Reka

0 votes
Leonard Chew Community Leader Feb 19, 2020

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.

Reka

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Next-gen

Keyboard shortcuts have arrived for next-gen projects!

...ollected feedback from users around the lack of shortcuts, and we’re here to address that: In next-gen projects, I miss the keyboard shortcuts badly. This is particularly true on the Board, but also i...

439 views 4 9
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you