Skip to main content

Should items pulled into a sprint be reflected in the sprint burndown?

Last post 06:41 pm June 4, 2019 by Daniel Wilhite
3 replies
09:56 am June 4, 2019

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?


02:40 pm June 4, 2019

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.


03:39 pm June 4, 2019

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.


06:41 pm June 4, 2019

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)

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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.