Sprint Backlog

Depending on how quickly products are needed in the marketplace and the finances of the organization, one or more Scrum teams work on a product’s backlog. As a Scrum team is available (newly formed or just finished a Sprint) to work on the backlog, the team meets with the product manager. Focusing on the highest priority backlog, the team selects that backlog which the team believes it can complete within a Sprint iteration (30 days). In doing so, the Scrum team may alter the backlog priority by selecting backlog that is mutually supportive, that is, that can be worked on at once more easily that waiting. Examples are multiple work items that require developing a common module or interface and that make sense to include in one Sprint.

The team defines the Sprint goal that they will meet during the Sprint by developing these backlog items (such as "demonstrate personalization capability"). The goal should be broad enough that the team can meet it in a variety of ways : it should specify what, not how.

Build the Sprint Backlog list. This is a list of all the tasks/activities needed to develop the Product Backlog selected for this Sprint.

In the Sprint Planning Meeting, the team decides the Sprint Backlog, with individual team members defining, signing up for (Owner), and estimating the initial work for each item.

During the Sprint, the owner of the Sprint Backlog item is responsible for maintaining the status of the item and - as the item is worked on - changing the amount of remaining work on the task.

The Remaining Work for a Sprint Backlog item is used to generate a burndown or burn-up of all work in the sprint.

 

Suggestions/Notes:

  1. One approach used to create Sprint Backlog is to identify all sprint deliverables needed to meet the goal, then figure out what tasks need to be performed to produce those deliverables. This is similar to development of a typical work breakdown structure.
  2. Consider creating the Sprint Backlog in a team meeting, probably lasting at least 1/2 day.
  3. Suggest not breaking tasks down to less than 4 hours. A good rule of thumb would be to never exceed 300 tasks in the sprint backlog list.
  4. Teams can add or subtract to sprint backlog as they learn more about the work that needs to be performed. Customers and management are not allowed to add or subtract to sprint backlog.
  5. It may be useful for the team to link dependencies between tasks in order to set up internal milestones and develop an understanding of the overall sequence of events. Use a pert chart as a way of sketching things out.
  6. Use the same tool mechanism that is used for the master backlog list for sprint backlog (e.g. Excel spreadsheet, defect tracking system, Project Control Facility, etc.). This will minimize the number of tools the development team needs to be familiar with.