Sprint backlog

The sprint backlog is the set of items that were selected at the start of the sprint to achieve them during the sprint following the sprint objective.

Sprint backlog definition

As I explained in the introduction to this article, the sprint backlog is the set of items that the team select during the sprint planning with the aim:

• answer at the sprint goal
• to increment the product of new things:
  • new functionalities
  • requirements
  • new functions
  • fixes
  • improvements
• the plan to deliver the selected items (technical sub-tasks, prioritization …)

Indeed, some teams forget to define the plan to deliver all the items of it.

The development team will create a new sprint backlog at each sprint. Indeed, the product owner is not responsible or owner of it.

The defined scope remains provisional

The sprint backlog remains a “forecast”; And the development team can not be sanctioned if its content is not delivered in a stable environment at the end of the sprint, .

If the development team can not reach the sprint goal, they will benefit from the sprint review to analyze the reasons.

The peculiarities to know

Sprint backlog always in continuous improvement

Each new sprint backlog must have one of the axis of improvement defined during the previous retrospective sprint. The presence of this item is very important to insure the continuous improvement.

The sprint backlog has a variable scope

Although the sprint backlog is defined at the start of the sprint, it continues to evolve throughout the sprint. Teams can add, modify or delete items based on their findings.

Moreover, its plan can also change throughout the sprint to take into account the latest explorations of the development team.

Here are some possible items that you can add:

• new technical sub-tasks (of one item)
• spike to do exploration
• forgotten test cases (functional/technical)
• …

The variation of the content and its plan have to always take into consideration the sprint goal to reach.

Estimates of the remaining work

The scrum guide reminds the importance of updating the remaining work on each item when the development team has done work on it (even unfinished).

An artifact that promotes transparency and real time

Although the scrum does not specify the nature of transparency to have, the sprint backlog must be visible to all. The development team will be responsible for it and will have to maintain it in real time; indeed, this real-time maintenance will allow to have a better transparency on the team work.

The development team should at least once a day (potentially at the daily sprint), calculate the remaining work to be done in order to have a good vision of the remaining course to achieve the sprint goal.

To conclude about this topic of sprint backlog, scrum teams usually use the burndown chart to do this work.