 | The Sprint Backlog |
With the top 20% of the Product Backlog well-refined, the PO must determine what stories should be included in the upcoming sprint. This will occur in the Sprint Planning meeting – one of the key scrum ceremonies.
In Sprint Planning, the Dev Team will ask questions about the stories that the PO presents and use estimation to determine how many can reasonably be completed in the next sprint. The selected stories are placed into the Sprint Backlog – the artifact representing the subset of Product Backlog that are to be completed during a given sprint.
The Dev Team “owns” the Sprint Backlog, meaning that they can break the Stories into Tasks (more technical in nature than the stories themselves) and complete them in any order and by any team member they wish, as long as all stories are completed by the end of the sprint.
By default, stories selected for the Sprint Backlog are taken from the top of the Product Backlog. This makes the most sense because PB ordering is determined by the PO, meaning that the items at the top have been pre-prioritized. There are some exceptions, though. Say, for example, that the first 5 stories in the top of the Product Backlog fit comfortably into the upcoming Sprint Backlog (based on their estimated Story Value), leaving plenty of room for a 6th. If the 6th story in the PB is estimated to be too large to fit in the remaining space, the 7th can take its place, leaving the 6th item for the next Sprint Backlog.
The next subsections will go into more depth on how teams estimate the “size” of each story and determine the number of stories that can be pulled into a given Sprint (Backlog).