2

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?

3

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.

3

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:

enter image description here

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.

  • Looking at the answers there seems a consensus about not rebasing the ideal line. Thanks for your answer too. I understand that rebasing may misinform the viewer. However the examples you give are not valid because they refer to actual work done. That will be visible regardless of rebasing the ideal line. The one actual example of misinformation due to rebasing is stated in the answer by StefanoLP: "Was the team committed to complete 100 or 105 story points?" – Christiaan Westerbeek May 14 '15 at 8:06
  • @ChristiaanWesterbeek They are valid. Rebasing the ideal line has the exact same problem. The team did not commit to 105 or 160 points; they committed to 100. Anything else was a scope change mid-sprint, and should not affect the base point of the graph. – Todd A. Jacobs May 14 '15 at 15:07
  • Then I don't understand: "e.g. that a ... Sprint put together". All those things are visible if you rebase the IDEAL line or not. Or I don't understand what rebasing means. The single argument against rebasing that I understand and agree with is: "pretending that the work was enqueued from the beginning" – Christiaan Westerbeek May 16 '15 at 8:35
2

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.