Sprint Backlog

What is sprint backlog?

The Sprint Backlog is a list of tasks that the Scrum team committed to doing by the end of the sprint. These items are picked from the Product Backlog by the team during the Sprint Planning Meeting based on the priorities set by the Product Owner and the team’s vision of time it will take to finish the various features. The Sprint Backlog is a detailed plan with complete information that helps to understand the changes in development clearly in the Daily Scrum. Throughout the sprint, the Sprint Backlog is modified only by the development team. They plan to finish the Sprint Backlog tasks during the Sprint, and so it belongs completely to the development team.


The above figure shows how the requirements are prioritized to Sprint Backlog.

Why is Sprint Backlog essential?

It is a popular practice in Scrum which provides a noticeable portrayal of the status of the User Stories constantly in the backlog and is represented on a task board or Scrum board. The Sprint Backlog makes the teamwork visible which the team identifies as important to accomplish the Sprint Goal. To follow the continuous improvement, it adds a minimum of one high-priority process improvement discovered in the last Retrospective meeting.

Though the tasks that are missing from the committed user stories can be added to the Sprint Backlog, it is necessary to ensure that new user stories are not added once the Sprint Backlog is committed and finalized by the Scrum team. If any new requirement emerges during a Sprint, they should be included in the overall Prioritized Product Backlog and added in a future Sprint.

What are the characteristics of the Sprint Backlog?

• The Sprint Backlog has a dynamic nature because each Sprint has repeated changes to reach the goal. A good practice keeps the Sprint backlog to reach the goal as stable as possible during Sprint.
• During the Sprint planning sessions, the team members go back to picking the prioritized specifications from the product backlog for the Sprint cycle.
• The Sprint Backlog is an outcome of the Sprint planning meeting sessions.
• The Sprint Backlog makes easy in identifying the work to the development team as ‘necessary’ to meet the Sprint goal.
• Here in this session, the Scrum team effectively works on preparing how the user stories would be implemented in the sprint by dividing those into further sub-tasks and estimation of it.
• The Development team owns the Sprint Backlog.
• For each Sprint, the team members create a planning document based on the requirements and market value priority in the product backlog before starting the sprint.

Who all are responsible for creating the Sprint Backlog?

The development team creates the Sprint Backlog which is nothing but a plan in terms of how the team is going to achieve the Sprint Goal.

When do we create a Sprint Backlog?

The Development Team creates the Sprint Backlog during Sprint Planning. Team members are supposed to update the Sprint Backlog during the Sprint as new information will be available.

How to create Sprint Backlog?

The team selects the items they wish to work on from the Product Backlog, adds them to the Sprint Backlog and then breaks down the selected PBIs (Product Backlog Items) into Sprint tasks to make the work simple. The team will make the decision on how to make it go more smoothly. The best approach is to show the Sprint Backlog on a task board, using index cards or Post-It Notes. They maintain it electronically as well like a digital task board or an Excel-Sheet. The figure below demonstrates an example of how such a task board could be structured. This structure should be set to show the project needs.

Tips to create a high-quality Sprint Backlog

• Ensure that each team member is involved in the process
• Identify all kind of tasks
• Have a definition of Done
• Discuss how to implement every item
• Don’t assign tasks in advance
• Assess the sprint commitment
• Develop the Sprint Backlog during the sprint
• Don’t spend too much time

Verification of Sprint Backlog

Analyze the following general statements before finalizing the Sprint Backlog and make the changes as required.

• Check for impediments
  Can the stories in the Sprint Backlog be finished within the sprint?
  If so, adjust as needed and resolve them.
• Definition of Done
  Are we able to deliver the product at the end of this sprint?
  Make sure that you are including everything from the respective team’s definition of Done.
• Backlog items missed
  Have we missed any work that needs to be done, but not included in the Sprint Backlog, including release planning activities, any items or any other activity that needs to be done in this sprint?
  If that is the case, add them to the Sprint Backlog, estimate them and adjust the backlog as required to finish within the time agreed by the team.
• Commitment
  Can we commit to our sprint plan? Can we explain how we plan to deliver the sprint?
  If yes, then go along with the plan and work accordingly.
• Taskboard setup
  Is our sprint plan depicted in the Agile tool or on the task board completely? Are we set to begin our sprint tracking?
• Risks
  Are there any risks that we need to be acquainted with during the sprint?
  If yes, fix these things in the sprint plan.

How to manage the Sprint Backlog

• Every team member should pick the work of their own choice- it is never assigned
• Remaining estimated work should be updated daily
• Any individual can add, change or delete the Sprint Backlog Item whenever required
• If the work is confusing, set a larger amount of time to the Sprint Backlog Item and break it down later

How does a Scrum Team accomplish a Sprint Goal?

During every Sprint, the Scrum team members pick the user stories from the backlog on top of its heap. These stories will have a time-boxed Sprint that is based on the average velocity of the team members. Each and every user story should have a Point value allocated to it based on the evaluated amount of relative effort it will take to finish the story. It is important to note that the Scrum Team estimates stories in Points but not in hours. The team decides how the work can be done best through the Sprint Backlog. However, when it is possible, they have to work on the high-priority value items first.

The development team implements technology and functionality in order to achieve the Sprint Goal. If anything turns out to be different from what is expected, they will collaborate with the PO to discuss the Sprint Backlog within the Sprint.
As the development team decides the work to be done in the sprint for each user story, answering the following questions might help you throughout the planning process.

• What is the next top-priority item that needs to be delivered this sprint? Plan to work on that next.
• What else do we need to know about this user story? Is the output clear? Does the acceptance criteria completely describe the requirements of the user stories, and are they clear?
• What is our strategy to deliver this story on time? List the things you need to do.
• Do we know the approach to implement this story?
• What is the estimated effort for the work required to deliver this story?
• Are we assessing all the work that is required to get the story “Done”?
• Are we planning to do the work now? Is it evaluated properly?

Note: Not all the questions will apply to each user story and every team.