Home Category Based List Agile The Artifacts of Scrum

Main Menu

Infotainment

The McKinsey Quarterly


The Artifacts of Scrum PDF Print E-mail
Written by Kevin Thompson   
AgileIntroduction

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.

The Story

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:

    Name: Planner enters new contact into address book
    Description: Planner enters standard contact information (first and last name, two street address lines, city, state, zip / postal code, country, etc.) into contact-entry screen. He clicks “Save” to keep the data, and “Cancel” to discard data and return to previous screen.
    Screens: http://myserver/screens/contact-entry.html
    How to test: Tester enters and saves the data, finds the name in the address book, and clicks on it. He sees a read-only view of the contact-entry screen, with all data previously entered.
There is no standard format for stories, but this example shows some common elements.

    1. Name: The Name is a descriptive phrase or sentence. The example uses a basic “Role-Action” organization. Another common style, popularized by Mike Cohn, follows the template “As a <type of user>, I want <some goal> so that <some reason>.” The choice of template is less important than having a workable standard of some kind.
    2. Description: This is a high-level (low-detail) description of the need to be met. For functional (user-facing) requirements, the description is put in narrative form. For non-functional requirements, the description can be worded in any form that is easy to understand. In both cases, the key is that the level of detail is modest, because the fine details are worked out during the implementation phase, in discussions between team members, product owners, and anyone else who is involved. (This is one of the core concepts of Scrum: Requirements are specified at a level that allows rough estimation of the work required to implement them, not in detail.)
    3. Screens: If the Story requires user-interface changes (especially non-trivial ones), the Story should contain or link to a prototype of the changes.
    4. How to test: The implementation of a Story is defined to be complete if, and only if, it passes all acceptance tests developed for it. This section provides a brief description of how the story will be tested. As for the feature itself, the description of testing methods is short, with the details to be worked out during implementation, but we need at least a summary to guide the estimation process.
Stories are used to describe functional and non-functional requirements, but these requirements do not describe all of the work done by software developers. The other category of work is that of bug fixes. Customer support, services, and engineering personnel frequently enter bug descriptions into some kind of bug-tracking tool, and these bugs ultimately imply work to be done, just as Stories do.

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.)

Conclusion

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.com). Kevin manages "agile" software development projects using the Scrum process framework. He provides training and mentoring in Scrum for businesses that want to become more agile, and writes about Scrum for several Web sites. He has a Ph.D. in Physics from Princeton University, and is a Certified Scrum Practitioner (CSP), Certified Scrum Master (CSM), and Project Management Professional (PMP). His Scrum in Practice workshop through cPrime (www.cprime.com) trains teams, Program Managers, and PMO personnel on the nuts-and-bolts of how to implement Scrum for software development.

 
Comments (3)
3 on Saturday, 24 November 2012 14:35
Jim
Hi Kevin, although stories on by far the most common way of expressing the requirements in SCRUM, I think it would be helpful to let people know that SCRUM doesn't actually prescribe the use of stories. User stories, as I'm sure you know, originated from XP like many other things things that many people think are defined by SCRUM guidelines.
2 on Sunday, 01 November 2009 16:17
Kevin Thompson
Bina,

Bugs are just another form of reuirements. They should be prioritized and ranked in the Sprint backlog with the Stories, based on how important they are, whether they are small or large. (Some bugs may require major changes, and need to be handled by creating multiple stories to cover all of the needed work.)

The exception to the above policy is the 'emergency bug,' which has to be fixed RIGHT NOW. In that case, the team has to devote work to the bug, and its capacity to work on the defined Sprint requirements decreases. This is a tradeoff that everyone should understand.
1 on Friday, 30 October 2009 00:00
Bina
Thanks for this very easy to understand explanation of the artifacts. You mentioned bug fixes - major bug fixing would become a story that I assume gets pushed to the Sprint backlog but how would you handle minor bug fixing that just requires a lot of time ? Is there a standard way of integrating them in the Sprint?

Add your comment

Your name:
Your email:
Comment:
  The word for verification. Lowercase letters only with no spaces.
Word verification: