Burndown chart and planned stories at the start of a sprint

[Brad Lackey]

It seems as though the total points and total tickets shown in the burndown chart at the end of a sprint is never the same as what they were at the start of the sprint when the sprint "backlog" was initially baselined, if you will...but instead shows where the sprint ended based on what tickets remained in the sprint at the time it was closed.

Meaning, if the sprint is started with tickets A, B, and C for a total of 7 points, but when i closes...for whatever reason...it has tickets C, D, E, and F for a total of 10 points, the burndown chart will be based on 4 tickets and 10 points instead of 3 tickets and 10 points.

Is this how it actually works? And if so, what is the logic for doing it that way? Not sure I have an argument either way. I just want to fully understand because we capture team-level reliability (not "performance") metrics at the end of each sprint.

Thanks in advance!

[Nic Brough -Adaptavist- · Accepted solution]

This is, in most cases, perfectly normal.

I am going to vastly over-simplify here, but the point of Scrum is that you have a time-box, at the beginning of which, you say "we will deliver a set of things (of varying sizes)", and at the end of it, you measure what you said you would do against what you delivered.

In your example, you committed to delivering items A, B, and C, whose sizes add up to 7.  In an "ideal" sprint (which is very very rare), you would deliver A, B and C, and when you do, their sizes still added up to 7.

What is happening in your case is that people are adding C, D, E and F (with 10 points total) into the sprint as you go, so yes, your burndown is going to show that they were added.

You should go ask the team why they are adding those items into the sprint? 

It's really not a bad thing to add them - one of the big tenets is that if you manage to complete A, B and C before the end of the sprint, hell, yes, do more things.  But if A, B and C were not complete before you drew them in, or worse, A, B or C were not complete at the end of the sprint, you have a huge problem.

The burndown chart is trying to reflect what you did, measured against what you said you did.

I do not know your processes or how you are working, but the starting questions I ask of clients when I see these sort of odd numbers (and I see them a lot) are:

• Why are people adding to an active sprint, and how?
• How is your board configured to handle "done"?
• Are people thinking of sub-tasks in the right way?  (if used)

[Brad Lackey]

Thank you! This at least confirms that I'm not crazy. :)

Many of the tickets added to an active sprint are bugs that were brought in after an individuals targeted tickets were completed, or were deemed a high priority for timely resolution regardless of where their other targeted work stood. 

Done is completed and pending release. We will carry tickets to the next sprint if they are not "done/done". So that is expected.

We don't currently use sub-tasks -- we try to stick to "a story is a story is a story." 

Cheers!

Brad