The Development Team creates a new Sprint Backlog during Sprint Planning. From that moment on, it becomes the current commitment for the Developers, i.e., a list of new functionalities, enhancements and modifications to the Product to implement in the starting Sprint. After the start of a Sprint, the Backlog becomes a binding queue from which Developers choose tasks to perform.
What is a Sprint Backlog? – table of contents:
- How is the Sprint Backlog created?
- What does the Sprint Backlog contain?
- Using the Sprint Backlog
A Sprint Backlog describes the work of the Development Team during a single Sprint. Therefore, it is expressed in technical language. It describes detailed tasks and their planned solutions. Thus, it consists of a list of tasks drawn up in a way that is clear to Developers. The Sprint Backlog usually takes little account of the business value language of the Product, a way of description proper to the Product Backlog, which we’ll introduce here.
The Sprint Backlog arises:
- based on the Product Backlog
- for the duration of one Sprint
- during a Scrum Event called Sprint Planning
- by the entire Scrum Team – but the Development Team the key role in its creation
How is the Sprint Backlog created?
During Sprint Planning, the Product Owner proposes how to add value to the Product in the next Sprint. Then the whole Scrum Team works together to formulate the Sprint Goal, i.e., selects which functionality from the Product Backlog to implement. The Sprint Goal defines how to implement the Product or postpone the deadline to meet the Customer’s expectations.
The next step is to think over and set realistically the scope of work to do in the next Sprint and how to achieve it.
The results of these findings come in the form of a technical description of the tasks to perform. And this list becomes the new Sprint Backlog.
The newly created Sprint Backlog exists in a location that is easily accessible to all members of the Development Team. In the physical space, it is usually a whiteboard hanging in the workspace. Whereas in the digital space, it exists as a cloud-based shared document that all Developers can update. Even though every member of a Scrum Team should keep it updated on daily basis, it’s the Scrum Master or one of the Developers who usually take on that responsibility.
What does the Sprint Backlog contain?
The Product Backlog does not specify how exactly to execute tasks. It’s the Development Team’s role to decide. That move creates enough space for the team to maneuver thus enhancing its self-organization capabilities. Also, this freedom to select the sequence and methods of action empowers each Developer rendering a sense of independence and responsibility.
The same idea applies to treating the Sprint Backlog as an unordered list of tasks to execute. Contrary to the traditional push model (where the Team or Developer acts according to a predefined and imposed agenda), in the pull model, the Developers select which tasks to do (pull model).
The Sprint Backlog specifies:
- The Sprint Goal – i.e. an answer to the question of why to perform the scheduled tasks this Sprint
- The list of new Product features and enhancements to develop in this Sprint.This is because it contains the Product Backlog elements selected for implementation in this Sprint.
- The list of tasks to perform – that is, a technical description of how and by whom the work that will result in Incremental…
Using the Sprint Backlog
Various metric tools reflect the progress of work written in the Sprint Backlog. Most often it’s the Burndown Chart, which we will fully cover in a dedicated separate article. With such a visualization, the Development Team can easily see whether the work on the Sprint Goal is proceeding according to plan.
It may happen during a Sprint that you find that the work plan has been blueprinted unrealistically. In other words, the number of to-dos in the Product Backlog Sprint Goal is too high or too low. In either case, the Developers and the Product Owner get down to find out what changes to apply to the current Sprint Backlog. It is possible to reduce the amount of work, select additional tasks from the Product Backlog or extend the already planned solutions. However, keep in mind that the Sprint Goal itself has to remain unaltered.
A Sprint Backlog is a list of tasks that Developers plan to do during one Sprint. It is a kind of detailed contract with the Product Owner. The Sprint Backlog arises during Sprint Planning in which the whole Scrum Team participates. The Burndown Chart reflects the degree of completion of tasks accepted for implementation.
If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing