Should the ideal line in a burndown chart be changed when story scope changes during the Sprint?

Question

At the start of the Sprint right after the Sprint Planning, we can already draw a burndown chart with an ideal line. It's a straight declining line starting at the top left with the total amount of story points in the Sprint backlog. Let's say a 100 points. It goes down to 0 at the end of the Sprint.

When the team went faster than anticipated, the actual line drops below the ideal line. Let's say the team decides to add more work. That means more may actually become done in the Sprint.

In that case should the starting height of the ideal line be corrected for the added work? So it was at 100 points. Should it now start at let's say 105?

Answer 1

The Development Team has completed all the stories that were planned for a particular Sprint.

In this case, the team usually decides to speak with the Product Owner to select other stories from the Product Backlog (possibly related to the current Sprint Goal) that can fit within the remaining Sprint time.

It is important to underline that, if the Development Team is not able to complete the selected additional stories, the Sprint will not be compromised.

I want to add that, if the team finishes early and works on additional tasks in several sprints, this is a sign that the team is, for some reasons, under committing (when this happens, it is usually because the stories are overestimated).

The burn-down chart should always reflect the work of the team during the sprint.

When a team is over delivering I prefer to keep the burn-down chart as it is, showing that the team has arrived to 0 (that is to say, completed all the stories in the Sprint Backlog) before the ending of the Sprint.

I would avoid to modify the burn-down chart as you proposed. In my opinion, management can misinterpret such a chart ("Was the team committed to complete 100 or 105 story points?"). To keep track of the additional stories I usually add another chart to the Scrum board: a burn-up chart (the curve goes up, instead of down) that I use to track how much work the team has completed in the Sprint.

Answer 2

Never Rebase the Starting Values of a Burn-Down Chart

Burn-down measures work remaining in the iteration. For example, if you start a Sprint containing 100 points, complete 50 points worth of work in the first two weeks, and then add 60 points of new work in the third week, you don't rebase the starting value. Instead, you show a rise in the amount of work remaining for the iteration. For example:

Since you didn't start the iteration with 160 points, rebasing the graph would misinform the viewer as to what really happened, e.g. that a significant chunk of new work was added mid-sprint. In the example above, the 60 points that were added in week three of a four-week Sprint clearly communicates when the new work was added, how much was added, and also shows that the amount of work completed in week four exceeded all the work done in the first three weeks of the Sprint put together.

Time, capacity, and efficiency information would be lost if you rebase your starting value, since it would no longer show work remaining over time, but instead would be pretending that the work was enqueued from the beginning. This is misleading, and will prevent process issues from being properly identified and accurately communicated.

However, you may find that you need to adjust the scale of your graph to accommodate work-remaining that is higher than your starting value. In this case, the graph now goes from 0-120 instead of 0-100 in order to accommodate the burst to 110 story-points remaining in Week 3.

Danger, Will Robinson!

Please note that unless stories were wildly mis-estimated, this type of successful swing in the burn-down (e.g. when work-remaining goes up dramatically, but the team still completes all work) is unlikely to happen in the real world. While you may frequently see small jumps where work-remaining increases rather than decreases due to new information uncovered during the Sprint or additional story-related tasks that must be added to the Sprint Backlog to meet the Definition of Done, large increases to the work remaining without a related change in team capacity or efficiency is a project smell that your burn-down chart has uncovered for you, and which the team must carefully inspect for process problems.

Use irregularities in the burn-down to identify problems with estimation, capacity planning, or scope-creep by tracking work remaining without retconning the baseline. Doing anything else simply papers over a process problem that should be made visible for the team to address during a Sprint Retrospective.

Answer 3

I will rather use a Burn up Chart using points to Measure progress with two metrics:Work accepted and Project scope