Wrong Burndown Chart for Sprint from multiple Projects

Martin V_ February 4, 2019

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?

 

Burndown-fail.jpg

Burnup Chart:

Burnup-fail.jpg

 

Kind regards,

Martin

 

2 answers

1 accepted

1 vote
Answer accepted
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 5, 2019

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

Martin V_ February 7, 2019

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

Like Earl McCutcheon likes this
Martin V_ February 11, 2019

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:

  1. ONCE create 2 projects 
  2. ONCE create an agile board
    • board type is "Scrum"
    • from existing projects (select both projects)
  3. select the new board via list
    • is there a problem with the exisiting old boards "DEV Board" and "PA Board"?
    •  boards.jpg
  4. create a new sprint from Backlog page
  5. move tickets from backlog to new sprint
  6. 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?
  7. 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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 11, 2019

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:

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

Like Martin V_ likes this
Martin V_ February 12, 2019

Hey Earl,

thank you for the reference, I think this can be the answer.
I will try this "start time" problem in the next sprint and will follow the bug report.

 

Kind Regards,

Martin

Like Earl McCutcheon likes this
0 votes
Martin V_ February 18, 2019

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

Suggest an answer

Log in or Sign up to answer