The McKinsey Quarterly
Scrum is a lightweight agile process framework used primarily for managing software development. This article reviews the three basic artifacts of Scrum: The Product Backlog, Sprint Backlog, and Burndown Chart.
We can’t discuss the three official artifacts without reference to another Scrum concept: the Story, or User Story. The Story is the basic unit of requirements specifications for Scrum, and typically consists of a title and a brief, usually narrative, description of the desired capability. For example, a Story might resemble the following:
Bug-fixes can be treated (for scheduling purposes) as Stories, or re-written in Story form. The first approach suffices for bugs that represent a simple failure of something that should work. The latter may be necessary when the bug uncovers a major problem that takes significant design and corrective effort, and which is better represented by one or more stories than a single bug report. Either way, we will use the term Story in a generic sense, below, to include both real Stories and bug-fix requests.
The Sprint Backlog
The Sprint Backlog is the set of Stories planned for implementation in a Sprint (the “Sprint” being the standard 2—4 week development period). The Stories in the Sprint Backlog must be ranked in the desired order of implementation (a Product Owner responsibility). The ranking reflects both the urgency (value) of the story, and any dependencies that exist between stories.
In an ideal case, all team members would work on Story #1 until it is complete (meaning the implementation has passed all acceptance tests), and only then begin work on Story #2. This sequence continues until the team has worked through all Stories in the Sprint Backlog.
The importance of ranking becomes clear when we introduce the less ideal, but familiar, world where progress doesn’t go as well as expected. It may be that only 50% of the actual work required by the Sprint Backlog can actually be done in the time available. By working on Stories in rank order, we’ve at least completed the most important half of the Stories in the Sprint Backlog. If we had not ranked the Stories, or had ranked them by some other criterion, the team’s efforts in this Sprint would have delivered less value.
The Product Backlog
The Product Backlog is the set of all un-implemented Stories that have not been assigned to the current Sprint. Unlike the Sprint Backlog, there is no requirement that all Stories be assigned a rank. In practice, Product Owners usually have at least a rough concept of ranking for stories likely to be implemented in the next couple of months, and less so beyond that time.
Prior to the Sprint Planning meeting, the Product Owner must finalize the ranking of the top Stories in the Product Backlog. In this meeting, the team estimates the effort required to implement the top Stories in the Product Backlog, and the Scrum Master moves Stories into the Sprint Backlog, until the team’s capacity for the Sprint has been filled up.
The Burndown Chart
At the start of the Sprint, the team breaks down each Story into a set of tasks, with a time estimate for each, such that executing the tasks results in a completed Story. During the Sprint, the team member who completes a particular task marks that task as complete. Plotting the amount of uncompleted work against time from the start of the Sprint produces a Burndown chart (see picture).
The diagonal line from the top left to lower right shows the ideal “burn down” of work versus time, and ends with zero remaining work on the last day of the Sprint. The blue bars in the sample chart show the amount of work actually remaining each day. If the bars are below the diagonal line, the project is ahead of schedule; above, and it is behind schedule.
(The green bars are not part of the definition of the Burndown chart, but are convenient. They show the work associated with completed stories, and should go up over time.)
The Scrum framework is deliberately light in weight, and its lightweight nature is evident in the small number of artifacts it defines. We have reviewed the three defined artifacts here: The Sprint Backlog, the Product Backlog, and the Burndown chart. We have also described what a Story is (in my mind, certainly an artifact, though not one formally defined by Scrum). The Stories and Backlogs are used for planning and execution, while the Burndown chart is a means for tracking progress. Together, this simple set of artifacts enables teams to accomplish a great deal, with minimal overhead.
Figure 1 Sample burndown chart (from Rally agile Project Management application)
About the author: Kevin Thompson, Ph.D., is a Certified Scrum Practitioner and Project Management Professional, and publisher of the Deep Scrum weblog (http://deepscrum.wordpress.