# Sprint burndown chart question

I have a question about the burn-down chart. We have a project consisting of 4 sprints, with each sprint lasting 2 weeks (excluding weekends), a total of 10 days. Before starting Sprint 1, the overall sum of story points was 102. However, during the Sprint 2 planning meeting, we added two new items to the product backlog, adding 16 points. Then, in the Sprint 2 review meeting, we decided to remove two items, decreasing the total by 6 points.

In such a situation, do I need to calculate the ideal burn-down separately for Sprint 2 and Sprint 3 due to these changes? If calculated separately, the ideal line on the burn-down chart would not be a straight line to zero but would move up and down. Is this okay? Shouldn't almost all burn-down charts be a straight line from the initial story points to zero?

Also, if we completed items worth a total of 24 points by the end of Sprint 1, should we recalculate the ideal burn-down for Sprint 2 by dividing (102-24) by the remaining number of days(sprint2 to sprint4)?

Im so confused if my burndown chart can be like this

There are a few things to note here:

• Most teams treat sprint burndowns seperately from release burndowns
• Velocity is expected to change over time
• Scope changes (work added/removed) are to be expected in Scrum

A sprint burndown is typically a straight line and is used to see if the team is on course for sprint delivery.

A release burndown is for a combination of several sprints. It is not unusual for teams to use a burn up chart for the release, instead of a burndown, for the reasons you describe in your question. Burn up charts tend to be better at showing changes in scope.

Release burndown or release burn up charts are rarely straight due to variations in scope and velocity over time.

## TL;DR

What you should be looking for is not an ideal vector or straight line. Instead, you should be looking at whether the plans have deviated too far from your planning values to be reliable estimates.

Never retcon a Sprint chart after the end of the Sprint. However, you can re-baseline your burn-downs or release plans anytime you want when looking forward. Variations in the Y-axis of such charts are pretty normal throughout the project life cycle.

I wouldn't worry about minor blips. It's really only a concern when key goals are at risk due to hidden drag or unmanaged scope changes, commonly seen as significant deltas in the intersection with the target Y-value on the X-axis.

NB: The target is usually `0` for burn-downs, or the current maximum Y-value for burn-ups.

## Analysis and Recommendations

The purpose of a burn-down or burn-up chart is not to adhere to an ideal vector. Rather, the goal is to assist in estimating deviations from planned scope and schedule, and to identify when expectations may need to be reset.

A multi-Sprint chart is a release plan, not a per-Sprint burn-down of remaining work for the iteration. Since you shouldn't be making highly granular plans within an agile framework (because of the need to "embrace change" even late in the process) any chart should expect ups and downs as scope and objectives change over time.

When you see that there is too much work to do to meet the current Sprint Goal by the end of the iteration, your chart is telling you it's time to bring the Developers and Product Owner together to negotiate scope. It's also likely that you need to revisit how you're planning capacity for your Sprints, and how you're identifying the central coherence of the unified goal for the Sprint.

When you see too much work remaining or too much work added to the release plan to reliably meet the targets, then you need to revisit the schedule and scope of the release plan. You likely also need to inspect-and-adapt how work is being selected for the release plan, and how releases are being scheduled.

In Scrum, scope is generally the flexible constraint. However, release plans can often choose between scope and schedule for their key constraint, and you can collaborate with the Product Owner to determine whether it's better to adjust scope or schedule if the release plan is significantly out of tolerance.