The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
The sprint backlog is the set of developer stories that the team has committed to working on during the current sprint. A sprint backlog is created as part of the sprint planning ritual, and reflects the shared understanding of the team, the product owner, and the scrum master of what everybody will be working on for the coming sprint.
A sprint backlog consists of a set of feature stories. Each one of these stories emerged from the thinking process that came out of the product backlog, but may not reflect a specific item in the product backlog. The feature stories in the sprint backlog follow the story structure we described earlier.
The size of the sprint backlog for the current sprint is based on the negotiations that happened during sprint planning at the beginning of the sprint. Each story is estimated during the sprint planning, and the backlog as a whole should represent the total number of points that the team believes it can accomplish in the upcoming sprint. Each story has a point value, and that reflects the amount of work the team believes will be necessary to complete that particular story.
The order of the stories in the sprint backlog is established initially at the sprint planning ritual, but it’s the prerogative of the product owner to change the order of stories in the sprint backlog at any point during the sprint. The product owner may not add stories to the sprint backlog, or remove stories from the sprint backlog, but may rearrange them as necessary to indicate which stories are most important.
Note: Making Major Changes to Stories Within a Sprint
If a significant change needs to be made to the stories in the sprint backlog, and that change really can’t wait until the end of the sprint, the scrum master should stop the sprint and start a new one, with a new sprint planning ritual. Because of the interruption and the cost, this is a very drastic option. It should only be employed as a last resort, if it’s obvious that none of the work being done in the current sprint backlog is appropriate for the changed needs of the product owner.
During the sprint, developers pick stories from the top of the sprint backlog every time that they complete a story and need something new to do. Each engineer should choose the story at the top of the backlog, because that’s the one the product owner considers the highest priority in the current sprint. Picking stories that aren’t from the top of the backlog will result in work being done out of priority order.
Note: Working in Priority Order
Because stories are always chosen from the top of the backlog, engineers who have completed their work and are looking for a new story will usually end up taking on stories that aren’t in their specialization at some point. This is intentional, as it creates an opportunity for engineers to learn more about the code base, and gain experience outside of their area of expertise.
While it’s valuable to have the most skilled talent working on the stories that are most appropriate for their specialties, it’s also valuable for a team to share knowledge, so that everyone has a clear sense of what’s involved in developing and maintaining the whole product. This helps the team become more versatile, provides learning and growth opportunities, improves everyone’s ability to estimate new stories, and prevents mission-critical information from being the exclusive responsibility of one person. Finding the proper balance of efficient development and knowledge sharing is up to each team.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
