What is the Sprint Backlog and what role do the developers play when Generating the Sprint Backlog? The Sprint Backlog is an important aspect of the Sprint. It tells the team what work they expect to finish during the sprint.
Creating the Sprint Backlog
A 59 Seconds Agile Video Animation
Generating the Sprint Backlog for Developers
A 59 Seconds Agile Article
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.
Generating the Sprint Backlog: What Does Sprint Backlog Contain?
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.
Generating the Sprint Backlog: Dependencies
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.
Generating the Sprint Backlog: Input
To create an effective sprint backlog, there are several required inputs. Possibly the most important is the sprint planning meeting. In this meeting, team members work together to break down user stories into tasks. The Scrum team only creates tasks for enough user stories for the next sprint. Working on user stories for future sprints may end up as wasted effort. Not creating enough tasks means the Scrum team will not have enough work to stay busy for the entire sprint.
Sprint velocity is a very important metric for the sprint planning meeting since the Scrum team needs to plan out just enough tasks to take up the entire sprint. For developers, this means generating enough tasks for development and debugging to stay busy. Underestimating or excluding testing may leave developers without enough time to finish all of their tasks. Overestimating tasks, or allocating too much time for debugging may mean they finish work early and find more tasks to work on until the end of the sprint.
Generating the Sprint Backlog: Project Management
As with any style of project management, it is vital that the team have tools to track progress. In Agile, the Scrum team often uses the sprint planning meeting to decide on sprint tracking tools. They can discuss what tactics and software tools best fit one particular team. There are numerous tools and tactics available. What works for one team may not be best for another team. The main goal is to make sure that development is on pace to be finished by the end of the sprint. Developers must make sure that the sprint tracking tools account for development and testing. Just completing new development for a feature does not mean the entire feature is finished. They must be able to monitor and leave time for testing and bug fixes after developers have written the new code.
Prev <— Continue Reading —> Next
Learn More: The Agile Sprint Backlog
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
Learn More: The Agile Sprint Backlog
Creating the Sprint Backlog
A 59 Seconds Agile Infographic
Prev <— Continue Reading —> Next
Learn More: The Agile Sprint Backlog
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: