The Scrum Sprint Backlog | David Tzemach

As you probably know, Scrum teams work in short sprints of 2 to 4 weeks. During these sprints, the team uses the planning meeting to identify items from the backlog to deliver at the end of the sprint.

The sprint backlog is the plan that guides the team throughout the sprint. As a plan, it includes the sprint goal and enough information (technical and functional requirements) to allow the team to estimate the effort required to develop the stories and tasks required to achieve the sprint goal.

Like the Scrum product backlog, the sprint backlog is also a 'living" document that may change as it evolves after the sprint is started. Remember, the sprint backlog is owned by the Scrum development team and thus can be modified throughout the sprint as stories are worked on or when a task/story changes its status (in-progress, blocked, done, etc.).

Guidelines to Follow While Creating a Sprint Backlog

The sprint backlog has a decisive impact on the team’s ability to work within the Scrum framework. As such, let me share some tips that will help your teams to start their sprint on a good footing.

The team decides what to include

The Scrum development team has full ownership of the sprint backlog. Therefore, neither the Scrum Master nor the Product Owner (nor any external stakeholder) have the authority to dictate it to them. Rather, a better approach is to involve the whole team to discuss what subset of the product backlog to include in the sprint.

The team decides how to estimate each item

The development team is responsible for delivering the selected stories at the end of the sprint. As part of the delivery process, the team must include different activities such as coding, researching, testing, etc. These may affect the time they need to meet the definition of done and acceptance criteria of the story.

Definition of Done that is agreed on by the stakeholders

Every item in the sprint backlog must have predefined completion criteria the team can follow. It serves as a guideline as to the work to be done before a story can be delivered.

Ensure tasks are achievable

The tasks added to the backlog should be achievable in less than one day. It is important to follow this simple rule so if the team falls behind, it will enable them to quickly gauge status and whether the sprint is on track or falling behind.

Team members set ownership

There are many techniques to promote self-organization in Scrum teams. One of them is to let the team decide how to organize their work on their own. This increases the team’s growth as a unit and their sense of collaborative ownership. Therefore, instead of assigning work, one should encourage the team to select the work. In addition, we should allow them to decide who will own the task.

Keep updating it daily

Like the product backlog, the sprint backlog is a 'living' document that must be updated daily to reflect the real progress of the team. It is imperative that as the sprint evolves, the team updates the backlog based on the opportunities and challenges that emerge and affect the original plan.

Not updating the backlog daily can lead to work falling behind schedule and hurting the customer’s confidence in delivering the product complete and on time.

Moreover, not updating the sprint backlog is a big red flag. It indicates larger and more complex issues that exist in the team such as lack of commitment or ignoring the plan for the sprint or its goal.