Sprint Backlog

The Sprint Backlog is an ordered list of Product Backlog Items or Increments, preferably User Stories or Job Stories, that the Team believes it can complete during the coming Sprint. These items are pulled from the top of the Product Backlog during the Sprint Planning Meeting to achieve the Sprint Goal.

Each story should have a Point value assigned to it based on the Estimated amount of relative effort it will take to complete the story. It is important that the Team estimates in Points and not hours. The Team determines how best to work through the Sprint Backlog. However, when possible, they should work on the highest value items first.

Once the Team forecasts the number of stories they feel they can accomplish in the Sprint Backlog, there should be no additions or changes until the Sprint ends. However, if during the Sprint management or the Product Owner decide there is a feature of higher business value that needs to come into the Sprint, the Product Owner should use the interruption procedure.

If an interruption arises that so dramatically changes the priorities or scope of the Sprint and can not be dealt with as an interruption, the Product Owner may abort the Sprint. In this case the Team stops, a new Sprint Planning meeting is held and a new Sprint is started. This can be extremely disruptive to the Team so the Product Owner should be very leery of stopping mid-Sprint.

Note: Experienced Teams should use Yesterday's Weather to determine the number of points they should pull into the Sprint.

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers (anybody who is working on the sprint increment), it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers (anybody who is working on the sprint increment) work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.