What is a Sprint Backlog?
It represents the list of tasks identified by the Scrum Team in order to complete all the work assumed for the current sprint. The work assumed is represented by those items from the Product Backlog on which the team has agreed, during Spring Planning Meeting, to include them in the next sprint. These items, which are usually user stories but not only that, are split in one or more tasks, estimated and transferred to the Sprint Backlog.
Sprint Backlog is just a subset of Product Backlog. Really?
Why Sprint Backlog is not just a subset of the Product Backlog? At Product Backlog level, items are never detailed at task level and it makes to sense to do it in advance, but only when you will actually start working on them. Only then all the technical and functional aspects of a user story implementation are detailed and clarified together with the Product Owner and the rest of the team.
One critical aspect in defining the Sprint Backlog is the size of it: how many items the team should agree upon to include in the next sprint? The team should know its own capacity of work, or in terms of Scrum, its' velocity. The velocity defines how many units of effort a team can provide during a sprint. In Scrum, units of effort are called story points. Each user story has a certain amount of story points estimated to complete. This concept is an abstraction of the usual man-days or man-hours type of estimations and it is important because as long as the user story is not in work, it is not clear which developer will work on it, and each developer has its own pace. Estimating at the level of story-points helps on two aspects to:
- - give an idea about the complexity of the work, in relation with other user stories;
- - be able to define the set of user stories that will go in a sprint, based on the team velocity.
What is important to note is that, as a whole, a team has a certain velocity (a total number of story points implemented) which can be translated into a set of items from the Product Backlog. Since each item is estimated using the same unit of measure - story points, it is quite easy to establish how many items will go in the next sprint: starting with the highest priority ones, until the cumulative number of story points equals the velocity. If we cannot match the velocity number, always consider less items than more (this will act as a buffer).
The team velocity is determined in time, after a few iterations (2-3 sprints) when everybody will get a better understanding of the product they are developing.
Sprint Backlog is a living document; it is constantly updated with the status of the tasks (mainly on the daily basis, during Daily Scrum). The team can decide that some additional tasks are needed in order to finalise a user story, estimations needs to be updated, tasks are closed or removed.
One of the most important principle in Scrum is that we do not increase the Sprint Backlog with more user stories during the sprint. If is the case that a user story might not be completed during a sprint it is recommended not to be started (and finish the sprint earlier) since the main objective of a sprint is always to have a workable version of the product.
While the user stories are estimated in story points, the actual tasks that are placed in the Spring Backlog have concrete estimations in man-days or man-hours. That is because the tasks are assumed by actual developers, and each one can provide the estimations on the work he undertook.
The Sprint Backlog is usually maintained as a spreadsheet, but it is also possible to use issue tracking systems or any software products designed specifically for Scrum or Agile.
The spreadsheet will be updated daily in order to see the progress on the tasks. Based on that, a chart is build, called Sprint Burn-Down chart which usually shows how the cumulative effort estimated for the sprint is consumed as the sprint progresses (see an example below).
The effort might also increase after a couple of days, as the developers start to work on tasks and unforeseen issues appear and affect the initial estimations. After that, it is always down to zero (ideally).
Since the target is to always have a workable product at the end of the sprint, it might be the case that, if the effort remained to be consumed is still high as the sprint progresses (perhaps due to some re-estimations of the tasks) the team should decide to take out some of the not started user stories in order not to reach the end of the sprint with work in progress.
Sprint Backlog is a simple and very useful planning and monitoring tool. As is the case for all Scrum practices, even if is simple, if not applied correctly it is not useless but can cause damages to the project.
Some (final) thoughts
Don't forget that the Spring Backlog is not necessarily used only in agile software development but in many industries were Agile mindset can be applied.