The Sprint Backlog is an ordered list of Product Backlog Items, preferably User 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.
Experienced Teams should use Yesterday’s Weather to determine the number of points they should pull into the Sprint. 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.
Next Suggest Topic: Daily Scrum
Back to the Framework