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.
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.
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.
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.
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.
Analyze the following general statements before finalizing the Sprint Backlog and make the changes as required.
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.
Note: Not all the questions will apply to each user story and every team.