The third artifact used in the Scrum Framework is the Sprint Backlog. Once again, the purpose of this artifact (and of the other two) is to provide transparency that can be inspected. To understand how this artifact is used, it is necessary to understand how and why it is created.
The Product Backlog exists as long as the product does. Likewise, the Sprint Backlog exists as long as its sprint lasts. It is created at the beginning of each sprint and is discarded as soon as its sprint is over.
The Sprint Backlog is created during the Sprint Planning Meeting, an event that starts each sprint. The Sprint Planning Meeting is an event during which the Product Owner and the developers meet, negotiate, and agree on the scope of the work to be done during the sprint. The Product Owner and the Development Team agree on a sprint goal, which is an overall statement about the fundamental purpose of the sprint. After the sprint goal is set, the Product Owner and the Development Team negotiate and agree on a set of PBIs on which to work that will satisfy the sprint goal.
When the negotiation is over and the agreement has been reached, the Product Owner leaves. The second part of the Sprint Planning Meeting then starts. The purpose of this second part of the meeting is for the Development Team to make a plan for implementing the agreed-on PBIs. The selected PBIs and the plan for implementing them together make up the Sprint Backlog.
It is important to recognize that PBIs and Sprint Backlog items are fundamentally different things. When written correctly, Product Backlog items identify business problems that are to be solved. Sprint Backlog items, however, identify technical tasks to be performed. PBIs answer the question: What problem is to be solved? Sprint Backlog items answer the question: How are we going to solve it?
Write the HTML needed to show user ID and password boxes on the page, plus a Submit button labeled “Log On.”
Write the JavaScript needed to capture the button press and make an API call to the back-end system for validation.
Write the code on the back-end system to implement the API and validate the supplied username and password against the user database.
Create the appropriate tables needed for the user database. And so on.
This list of technical tasks should be as comprehensive as possible, In other words, if the team completes all the technical tasks on the list, it should have implemented the associated PBI completely.
That is not to say, however, that the list cannot change after the work is underway. If a new understanding of the business problem comes about during the sprint, the Development Team may add to, change, or delete items from the Sprint Backlog as they see fit.
Just as the Product Backlog is owned by the Product Owner, the Sprint Backlog is owned exclusively by the Development Team. It is their tool, and its sole purpose is to help the team manage itself to accomplish the sprint goal.
The Scrum (Kanban) Board
There are several common ways of representing the Sprint Backlog. The traditional way is by using a Kanban board. This can be as simple as taking a whiteboard or other flat surface and dividing it into three columns. Each Sprint Backlog item is written on a “sticky note” and is placed on the board in one of the columns. The first column is labeled “To Do,” the second is labeled “In Progress,” and the third is labeled “Done.” The column in which each sticky note is placed represents the task’s current status. At the beginning of each sprint, all the sticky notes should be in the To Do column. At the end of the sprint, they should all (hopefully) be in the Done column.
During the course of the sprint, developers take up tasks to work on from the sprint backlog. If they are using the traditional Kanban board, they pick up one of the sticky notes and move if from the To Do column to the In Progress column. When they finish the task, they move the note to the Done column. Thus, at any given time, a single glance at this “Scrum board” shows a complete picture of what has been finished, what is being worked on, and what has yet to be started.
The Sprint Burndown Chart
Another common way to represent the Sprint Backlog is through a so-called burndown chart. This chart is used to show a graphical representation of the pace of the work during a sprint.
The chart graphs the Sprint Backlog’s status over time. Its vertical axis represents the amount of work left to do at any given time. The horizontal axis represents the number of days in the sprint. The chart is plotted by recording the amount of work left to do on a day-to-day basis. At the beginning of the sprint, the plot mark is made at the top of the scale, indicating that all the work remains to be done. The next day, the plot mark is made one day to the right on the scale and also a little lower, reflecting the work that was finished that day. The amount of remaining work is plotted each day, creating a sloping line that shows progress toward the point in time when there is no work left to do.
The burndown chart often includes an idealized workflow reference line. This is a straight line drawn from the beginning of the sprint to the end of it, showing an idealized “smooth” completion of work throughout the course of the sprint. If a sprint contains ten units of work and has a duration of ten days, the burndown chart’s idealized reference line would show ten units of work remaining at the beginning, nine units remaining after the first day, eight units remaining after the second day, and so forth.
Useful information can be learned by comparing the idealized workflow reference line on the chart with the actual work completed. If, for instance, the idealized line shows that four units of work should have been completed but the actual line shows that five have been finished, then the team is ahead of schedule. Likewise, if the idealized line shows that three units of work should be left but in fact four of them are not yet finished, the team is behind schedule.
Both the Scrum board view and the burndown chart view of the Sprint Backlog give Development Team members valuable transparency about the status of their work. They need to inspect this transparency regularly to be sure they satisfy the sprint goal to which they agreed with the Product Owner. They do this inspection on a daily basis during a Scrum event called the Daily Scrum. The Daily Scrum is a daily opportunity for the Development Team to inspect the transparency provided by the Sprint Backlog and to adapt their work plan to implement the PBIs they agreed to undertake.
Summary
At the beginning of each sprint, the Product Owner and the Development Team negotiate an agreed-on set of PBIs to be delivered. This set of items plus the technical steps needed to implement them make up the Sprint Backlog. The Sprint Backlog is a key artifact because it helps the Development Team keep track of the work it needs to do to fulfill that agreement. It provides the transparency needed for team members to know whether they are on track or not.
The Development Team creates and owns the Sprint Backlog, and can change it any time it sees fit. No one else may do so. In fact, the Development Team need not share or show the Sprint Backlog to anyone outside its own membership. What it contains is, literally, no one else’s business.