Should items pulled into a sprint be reflected in the sprint burndown?
In planning the sprint we use story point estimations to size items and figure out our velocity. Once the sprint is planned we create tasks under each user story. Each task is given an 'hours' estimate and each person gives their 'hours' capacity for the sprint. We then track the relationship between the hours on the tasks with the hours capacity to figure out if we are still on track to deliver the sprint goal. We accept that the hours estimates won't be precise but the chart still gives a clear picture of how on-track we are, we have found.
We recently had completed the sprint work early and wanted to bring in other items. We got into a discussion as to whether the pulled-in items should have hours estimated against them and tracked on the burn down. I believe they shouldn't: In my understanding the sprint burndown is to help us judge progress to the sprint goal. Since the sprint goal has already been achieved the burndown does not need to track this additional work. Another memeber of the team argued that all work should be reflected on the sprint burndown. They had particular interest in this, as a senior member of the team, as they wanted to show the burndown in the review to communicate to the atendees that the sprint was achieved early and other stuff was pulled in (evidenced by the up-tick in the burn down).
I would love to hear other peoples thoughts on this. Do you think new items should be included in the sprint burndown?
I think that the right thing to do is to allocate the work to the Sprint and reflect this on the burndown chart (indicating an increase in items in the Sprint). Some of the core values of Scrum are visibility and transparency. Not reflecting the change in work doesn't seem to align with these values - stakeholders don't have insight that the planned work was completed early and additional work was brought in. Also, if you use these visuals and metrics as part of your Sprint Retrospective, it will help to make sure that the truth is reflected and can be discussed, again promoting honesty, visibility, and transparency into the work planned and work achieved.
We got into a discussion as to whether the pulled-in items should have hours estimated against them and tracked on the burn down.
What are the items being "pulled" into? If it's the Sprint Backlog, why would a Sprint burn-down fail to show it?
I believe they shouldn't: In my understanding the sprint burndown is to help us judge progress to the sprint goal. Since the sprint goal has already been achieved the burndown does not need to track this additional work.
Remember that the Sprint ends when the time-box expires, not when a goal is met.
Burn-down charts are expected to show the burn down of work within a Sprint. If you pull work into the Sprint, why wouldn't you show that work on the burn-down? What happens if the pulled in work isn't completed? How would you be transparent with that situation? Just telling the stakeholders that the goal was achieved early and other work pulled in doesn't tell the entire story.
Remember that a burn-down chart is not part of the Scrum framework. It is an adopted "best practice"used for monitoring progress of the work being done. I'm going to quote the Wikipedia (I know all of the arguments but in this case it isn't a bad quote) section on Burn Down Charts (https://en.wikipedia.org/wiki/Burn_down_chart) (as usual, emphasis added by me)
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time.