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; } } }

Wrong Burndown Chart for Sprint from multiple Projects

Martin V_

Hey guys,

I created a new Scrum-Board form 2 projects.

New Board -> From existing project -> Select 2 projects

Then I created a new sprint in this board, selected some tickets from both projects and I started the sprint as usual.

When I now look at the burndown chart, the forecasted line is missing.

Do you know what I did wrong?

Burnup Chart:

Kind regards,

Martin

Accepted answers

Earl McCutcheon

Hi Martin,

That behavior looks like either the issues were added to an active sprint or estimates were added to the issues in the active sprint after the start of the sprint triggering a Burn up event as unintentional Scope Creep.

In the status Report they will show with an Asterisk "*" for any issue added to sprint after start time.

Check out this Blog, "Inside Atlassian: 4 ways to deal with scope creep" for some additional tips, but ultimately you want to have the estimates on an issue and the issues added to a future sprint before you start the sprint otherwise all the issues are added out of scope for that defined sprint. With some additional Details here.

Regards,
Earl

All comments

Earl McCutcheon

Hi Martin,

In the status Report they will show with an Asterisk "*" for any issue added to sprint after start time.

Regards,
Earl

Martin V_

Hey Earl,

thank you for four answer. I can ensure that before I start a sprint, I first add story points (not estimated story points) to the tickets and then I add tickets to the sprint.

But you are right. If I look into the status report, the tickets are shown with an Asterisk "*" as you expected.

I will see if this behaviour changes on the next spint (starting on monday), maybe I really did something wrong...

Kind regards,

Martin

Martin V_

Hey Earl,

today I tried to start a sprint from tickets with story points several times, always getting a bad burndown-chart. And yes, the tickets are always shown with an Asterisk.

Again my steps to reproduce:

ONCE create 2 projects
ONCE create an agile board
- board type is "Scrum"
- from existing projects (select both projects)
select the new board via list
- is there a problem with the exisiting old boards "DEV Board" and "PA Board"?
create a new sprint from Backlog page
move tickets from backlog to new sprint
start sprint with custom duration
- is there a problem selecting an earlier time? Example: it is 10:14am and I type 10:00 am as start?
looking at burn down chart = looks like all tickets are planned after sprint start and no forecasted line

I don't see my mistake. Maybe you can reproduce it :S?

Kind Regards

Martin

Earl McCutcheon

Hi Martin,

Thanks for the repro Steps, and playing around with this the Forecast line error is occuring at the time adjustment for the custom sprint time you noted at step "6." and looks to related to the following BUG Report, where creating a new sprint within a minute of closing the previous sprint breaks the burndown reporting:

https://jira.atlassian.com/browse/JSWCLOUD-16052

When adjusting the start interval there must be some overlap (i.e. your previous sprint ended at 10 and you set the start time for the next sprint to 10 as well to line everything up after your planning completed) This is adding the issues to the sprint with an earlier or matching start time than the previous start causing a logic conflict and the the forecast line breaks and a burn-up occurs on a conflict with the previous sprint completion time.

If your custom date range is at least 1 full min after the completion of the last Sprint the Burndown report appears to be rendering in my testing without issue.

I already added a note to the BUG for some additional follow up, and I would recommend watching the report to get updates on the fix once available.

Regards,
Earl

Martin V_

Thanks to Earl, the solution is to never start a sprint in the past and avoid overlapping sprint starts/ends.
Discussion can be closed :]

Welcome!

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

Quick Links

Find more posts tagged with

jira

project

cloud

jira-cloud

atl-adm

burndown