Creating the Sprint Backlog for Developers

In Agile software development, the sprint backlog is one of the most used tools available. It consists of a set of tasks that must be finished by the end of the sprint. This differs from the product backlog in a few ways. The product backlog contains user stories rather than tasks. Also, the product backlog persists through the duration of the project, while the sprint backlog is cleared out after every sprint.

Components

While Agile seeks to minimize documentation, there are some components that the Scrum team must understand in order to communicate clearly. A frequently used term in Agile is “velocity.” In most practical applications, velocity refers to speed and direction. Although a Scrum team may not have physical motion, there is certainly an aspect of speed for each team member. Sprint velocity refers to the average amount of work finished in a single sprint. This can be measured in story points, the number of tasks, or other metrics used in Agile. Developers determine their velocity by observing the amount of work completed in previous sprints. Velocity can change over time but gives an idea of about how much a team can be expected to finish in any given sprint. Since the sprint backlog is designed to contain enough work to complete in a sprint, it is important that the quantity of tasks in the backlog closely matches the sprint velocity for the team.

Dependencies are also a vital part of the sprint backlog. A dependency is a feature that must be implemented before other features that depend on it to work. This is entirely the responsibility of developers. The developer role has the understanding of where feature dependencies may be, and what order features should be created to minimize delays in work. The sprint backlog must either have a feature and its dependency created in the same sprint, or the dependent feature may be postponed to a later sprint in order for work to be completed on the dependency.

Availability indicates how much effort each team member can contribute to the sprint. If some members have other responsibilities, they cannot dedicate all of their time to the sprint work. In these cases, each team member gives a percentage of availability. This percentage is taken from the sprint velocity to give an approximate velocity with that much availability. For developers, they must often continue supporting old code while working on new development. It is important that they allocate enough time for each responsibility.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: