International Product Owner Foundation

Steen Lerche-Jensen

12 CREATE SPRINT BACKLOG

12.1 Sprint Backlog

The Task List to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.

It is common practice that the Sprint Backlog is represented on a Scrum Board or Task Board, which provides a constantly visible depiction of the status of the User Stories in the Backlog. Also included in the Sprint Backlog are any risks associated with the various Tasks. Any mitigating activities to address the identified risks would also be included as Tasks in the Sprint Backlog.

Once the Sprint Backlog is finalized and committed to by the Scrum Team, new User Stories should not be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

Figure: Example of Sprint Backlog. Product Backlog Item, Tasks, Started Tasks, Done.

12.2 Sprint Burndown Chart

The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. A Planned Burndown accompanies the initial Sprint Burndown Chart. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and allows estimation errors to be discovered. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the Tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion and try to remove them.

A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.


Figure: Example of Sprint Burndown chart. Sprint Burndown, Remaining Effort, Day. Remaining, Ideal.

The initial Sprint Backlog defines the start-point for the remaining effort. The remaining effort for all activities is compiled on a daily basis and added to the graph. In the beginning, the performance is often not as good as predicted by the ideal burndown rate, due to inaccurate estimation, or impediments that have to be removed in order to get up to full speed.

12.3 Sprint Velocity

Sprint Velocity is the rate at which the Team can complete the work in a Sprint. It is usually expressed in the same units as those used for estimation, normally Story Points or Ideal Time. A record of the Sprint Velocity of the Team for each Sprint is maintained and used as a reference in future Sprints. The Previous Sprint Velocity becomes the most important factor in determining the amount of work the Team can commit to in a subsequent Sprint. Any changes in the situation, or variations in conditions since the last Sprint must be taken into account to ensure accurate estimation of Sprint velocity for the upcoming Sprint.

Generally, velocity remains fairly constant during a development project, making velocity a useful metric for estimating how long it will take a Team to complete a software development project. If the Product Backlog has 300 Story Points, and the Team is averaging 30 Story Points per Sprint, it can be estimated that the Team will require 10 more Sprints to complete the work. If each Sprint lasts two weeks, then the project will last 20 more weeks. If a Team member is moved to another project, however, or new members are added, then the velocity must be recalculated.


Figure. Example of Sprint Velocity Chart for Team A. Story Points Completed, Sprint.

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification