The Sprint Backlog is a set of Product Backlog items selected for the current Sprint, along with a plan for delivering a product increment to achieve the Sprint Goal. The Sprint Backlog defines what features the development team expects to include in the next increment and the work required to deliver them.

Scrum Sprint Backlog
The Sprint Backlog defines the work the development team needs to do to transform Product Backlog items into a “done” increment. It clarifies the work required for the development team to achieve the Sprint Goal.

Sprint Backlog
The Sprint Backlog is a sufficiently detailed plan that can be understood during the Daily Scrum to track progress changes. The development team will continuously refine the Sprint Backlog throughout the Sprint, and it gradually evolves as the Sprint progresses—such as when the team works according to plan and gains deeper insight into the work needed to achieve the Sprint Goal.
When new work arises, the development team must add it to the Sprint Backlog. As tasks progress or are completed, the estimated remaining effort for each task must be updated. If a part of the plan loses its development relevance, it can be removed. Only the development team can modify the Sprint Backlog during the Sprint. The Sprint Backlog is highly visible and reflects in real time the team’s plan for work completed during the current Sprint—it belongs exclusively to the development team.
Since Product Backlog items are fixed within a Sprint cycle, the following reasons may lead to changes in the Sprint Backlog:
- As time passes, the development team may gain a better understanding of the requirements and discover the need to add new tasks to the Sprint Backlog.
- Defects are added as new tasks—these are incomplete items from previous Sprints.
The Product Owner can collaborate with the Scrum Team to help the team better understand the Sprint Goal. The Scrum Master and the team may consider minor adjustments that do not affect Sprint progress but could bring greater business value to the customer.
Monitoring Sprint Progress
At any point during the Sprint, the total amount of remaining work on the Sprint Backlog can be calculated. The development team tracks all remaining work at least during the Daily Scrum and forecasts the likelihood of achieving the Sprint Goal. By tracking other work during the Sprint, the team can manage its progress effectively.
Scrum does not consider the time spent on the Sprint Backlog. We only care about the remaining work and the time variable.
Using Burndown Charts for Follow-up
Sprint Burndown Charts show the cumulative remaining work during the Sprint, reflecting the trend of work completion. The Y-axis represents the remaining work, and the X-axis represents the Sprint working days.

Burndown Chart
At the start of the Sprint, the Scrum team identifies and estimates the detailed tasks required to be completed. All tasks that need to be completed but are not yet finished are considered cumulative work. The team updates the cumulative work daily based on progress. If the cumulative work reaches zero by the end of the Sprint, the Sprint is successfully completed.
Release Burndown Chart
In a Scrum project, the team tracks the overall release progress by updating the release burndown chart at the end of each Sprint. The release burndown chart records the trend of the total estimated remaining work in the Sprint Backlog over a period of time. The X-axis represents the Sprint cycle, and the Y-axis represents the remaining work, typically measured in user stories, ideal person-days, or team-days.