The list of the tasks to be executed by the Scrum Team in upcoming Sprint is called the “Sprint Backlog”. This is the second artifact in Scrum.

It is common practice that the Sprint Backlog is represented on a task board which provides a constantly visible depiction of the status of the user stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the sprint Backlog.

Once the Sprint Backlog is finalized and committed to by the Team, new User Stories should not be added. However, tasks that might have been missed or overlooked from the committed User Stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future sprint.

The Sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking “Can we also do this?” and adding product backlog items to the sprint backlog. The Development Team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guide line of how much “effort” they can complete.

Representations of Sprint Backlog

In its most basic form, a Sprint Backlog is represented as a task board and can be drawn on a whiteboard or even a section of wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.

Sprint Backlog represented in the task board format

The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each sprint to reflect the sprint plan.

Some of the variations of the taskboards are depicted below