nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Remove sprint from Release Burndown Chart?

Reka Ferencz_h0pzd7

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

Accepted answers

Reka Ferencz_h0pzd7

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).

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

Thanks,

Reka

All comments

Leonard Chew

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)

Reka Ferencz_h0pzd7

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

Reka Ferencz_h0pzd7

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).

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

Thanks,

Reka

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

agile