Your Scrum Sprint Backlog

By Mark C. Layton

The sprint backlog is created in the scrum sprint planning session and is the ordered list of requirements and tasks necessary to achieve the sprint goal. A sprint backlog might contain the following information:

  • The sprint goal and dates

  • A prioritized list of the requirements (for example, user stories) to be developed in the sprint

  • The estimated effort (that is, story points) required to develop each requirement

  • The tasks required to develop each requirement

  • The hours estimated to complete each task (if needed)

  • A burndown chart to show the status of the work developed in the sprint

The burndown chart is generated from the sprint backlog. The sprint backlog should be updated every day, and only the development team can do this. At the end of each day, each developer updates their task (whether on a 3×5 card, on a spreadsheet, or in an electronic tool) by entering the number of remaining hours (not the number of completed hours) that are left to complete the task. That’s it. One number. It takes seconds and the results are invaluable.

A sprint backlog — a key scrum artifact.
A sprint backlog — a key scrum artifact.

The sprint burndown chart is an information radiator that shows anyone who wants to know the status of the sprint. Burndown charts get generated automatically as development team members update the amount of time left on their one active task at the end of each day. (You can download a sprint backlog and burndown chart template.)

The burndown chart shows the amount of time remaining for the sum of all the requirements on the sprint backlog. Compared with the trend line, it provides a daily level of status detail for a scrum team that you can’t get with traditional project management techniques.

Capacity for backlog

How much capacity is really in a day? If you’re looking at the number of hours per day that a development team member will actually be able to devote to his main job — developing! — allow for less than eight. Every organization has a certain amount of overhead. I find that for most organizations, somewhere between five and seven hours is a normal effective work day.

An average of 16 hours per week are wasted on unclear objectives, poor team communication, and ineffective meetings.

How much capacity is really in a sprint? In a one-week sprint, scrum teams will spend up to two hours in sprint planning, up to one hour in sprint review, and up to 45 minutes in a sprint retrospective. That’s about four hours in sprint meetings. (Do you have to use all four hours? No. Can you go over the limit for any given meeting? No.)

That accounts for four of the five scrum events (a maximum 15-minute daily scrum won’t impact development time), but don’t forget product backlog refinement. Development teams will, on average, spend 10 percent of their time each sprint in product backlog refinement activities. This translates to about three to four hours in a one-week sprint.

So, for a one-week sprint, each developer will spend between seven and eight hours in sprint events, which takes care of one full workday for an efficient organization and about a day and a half for a less efficient organization.

Is there any buffer in scrum? Sure there is. Consider that a development team has 165 hours available to them for a sprint. They shouldn’t take on 164 hours under the false assumption that everything is going to go exactly according to plan. Buffer will vary from team to team, but make it ­transparent.

So, capacity for one developer for a one‐week sprint would be between 18 and 27 hours, depending on the organization’s established effective workday. Take this into consideration when identifying a development team’s capacity during sprint planning. This is assuming that no paid holidays, vacations, or other time off is planned that will keep developers from developing.

Who said scrum is rudderless? You can’t get much more disciplined than this.

What an incredible impact having a dedicated and effective scrum master means to a development team’s capacity. By removing the organizational drag (impediments) that keep effective workdays from increasing from five to seven hours, the impact can add up to an additional nine workhours in a one‐week sprint per developer. For a development team of seven, that’s a potential 63-hour efficiency increase. Scrum masters add value.

What happens if at the end of sprint planning, the development team finds that the number of estimated hours for their tasks from the sprint backlog is more than their capacity? Do they hunker down and work overtime? No, the product owner has a decision to make: Which sprint backlog items will be moved back to the product backlog to get the number of hours below the development team’s capacity?

The value of the iterative planning process is easily visible within sprint ­planning. By the time the work to be done is outlined and broken down to the task level, you will have done so in a way that minimizes time waste and ­maximizes business value and ROI. This is because the roadmap to value, from the vision statement all the way down to the sprint level, has enabled continuous prioritization and progressive elaboration of only the most important product backlog items.

Working the sprint backlog

Development teams get distracted and go off target by making some common mistakes. Follow these practices to counter those mistakes when working with the sprint backlog:

  • Make sure that requirements are broken down into tasks that accurately and completely reflect your definition of done.

    The product owner should not accept a requirement until it completely satisfies the sprint definition of done.

  • The entire development team ideally works on only one requirement at a time and completes that requirement before starting another. This is called swarming.

    Swarming can be accomplished by such activities as

  • Each team member working on individual tasks related to the same requirement

  • Pairing two people on one task to ensure quality

  • Team members shadowing each other to increase cross‐­functionality

    As development teams swarm around one requirement at a time, this ensures cross-functionality and that every sprint will have something tangible accomplished at its end.

  • Each requirement must be fully developed, tested, integrated, and accepted by the product owner before moving on to the next ­requirement.

  • Don’t assign multiple tasks to individual development team members.

    Each day, the development team coordinates priorities and decides who will do what. A developer should only be working on one task at a time until that task is completely done. This is called a pull mechanism. Don’t fall back into the traditional method of a manager assigning tasks out to team members.

Swarming on requirements stems from the lean concept of work in progress (WIP) limits. When a development team has a lot of work in progress, it delays taking the actions necessary to finalize that work and rear‐loads issue correction. Your WIP limit should ideally be only one requirement at a time for the development team and only one task at a time per developer. The development team usually finds that their tasks get completed sooner than if they had started them all at the same time. Having only one requirement “open” at a time is also an effective way of exposing process bottlenecks, which can then be addressed and fixed for faster throughput.

Sprint prioritization

Each sprint has its own life cycle. Within each sprint, each requirement has its own prioritization and life cycle, too. Each requirement and task are developed, tested, integrated, and approved before moving on to the next‐highest‐priority item. See the following figure for a representation of this.

Prioritization within a sprint.
Prioritization within a sprint.

The sprint backlog items are prioritized from highest to lowest and developed in that order. Only one requirement is worked on at a time by the development team. When that requirement is finished, they move on to the next‐highest‐priority one rather than picking one lower on the list that might be easier or more interesting.