90 Scrum Artifacts

 

Scrum defines three artifacts: Product Backlog, Sprint Backlog, and Increment.

Product Backlog

 

Backlog Refinement

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. While Backlog Refinement is not a required event, it is a required activity. Most Scrum Teams find it useful to take a short time out of every Sprint for this activity. They get together to prepare the Product Backlog for upcoming Sprints.

In Backlog Refinement, large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team.

While refining items, the team may estimate the amount of effort they would expend to complete items in the Product Backlog and provide

 

 

top items are more granular

 

 

 

 

 

 

 

Figure 6: Product Backlog

 

 

 

 

User login

 

 

 

 

 

 

 

SSL enable

 

 

 

 

 

 

 

Reset lost password

 

 

 

 

 

 

 

Account lockout after

 

 

 

 

 

 

 

LDAP integration

 

 

 

 

 

 

 

Register a new login

 

 

 

 

 

 

 

Admin reporting

only one item at a time

is top priority

 

other technical information to help the Product Owner prioritize them.3

A skilled Scrum Master can help the team identify thin vertical slices of work that still have business value, while promoting a rigorous definition of “done” that includes proper testing and refactoring.

It is common to write Product Backlog Items in User Story form.4 In this approach, oversized PBIs are called epics. Traditional development breaks features into horizontal tasks (resembling waterfall phases) that cannot be prioritized independently and lack business value from the customer’s perspective. This habit is hard to break.

Agility requires learning to split large epics into user stories representing very small product features. For example, in a medical records application, the epic “display the entire contents of a patient’s allergy records to a doctor” yielded the story “display whether or not

• 
  Force-ranked (prioritized) list of desired functionality
• Visible to all stakeholders
• Any stakeholder (including the Team) can add items
• Constantly re-prioritized by the Product Owner
• Constantly refined by the Scrum Team
• Items at top should be smaller (e.g., smaller than 1/4 of a Sprint) than items at bottom

 

 

 

1 Agile Retrospectives, Pragmatic Bookshelf, Derby/Larson (2006)

2 The Art of Focused Conversations, New Society Publishers (2000)

3 The team should collaborate to produce a jointly-owned estimate for an item.

4 User Stories Applied: For Agile Software Development, Addison Wesley, Cohn (2004)

 

Product Backlog Item (PBI)

• Describes the what (more than the how) of a customer-centric feature
• Often written in User Story form
• Has a product-wide definition of done to prevent technical debt
• May have item-specific acceptance criteria
• Effort is estimated by the Development Team, ideally in relative units

Sprint Task (optional)

• Describes how to achieve the PBI’s what
• Typically involves one day or less of work
• During Sprint Execution, a point person may volunteer to be primarily responsible for a task
• Owned by the entire team; collaboration is expected

 

Account lockout af ter three attemptsAcceptance Criteria: ….Small
(e.g., story points)

determine requirements for password policy

page layout (design)

get latest JBoss

running

 

 

 

 

 

choose persistence strategy (Hibernate?)

write code (using test- driven

development

)

 

exploratory testing

 

 

 

 

Figure 7: A PBI represents a customer-centric feature, usually requiring several tasks to achieve definition of done.

 

Sprint Backlog

• Consists of selected PBIs negotiated between the team and the Product Owner during Sprint Planning
• No changes are made during the Sprint that would endanger the Sprint Goal
• Initial tasks are identified by the team during Sprint Planning
• Team will discover additional tasks needed to meet the Sprint Goal during Sprint execution
• Visible to the team

• Referenced during the Daily Scrum

 

Figure 8: Sprint Backlog is best represented with an “information radiator” such as a physical taskboard.

 

 

Increment

Figure 9: Sprint tasks required to complete one backlog item require a mix of activities no longer done in separate phases (e.g., requirements elicitation, analysis, design, implementation, deployment, testing).

 

Sprint Burndown Chart (optional)

• Summation of total team work remaining within one Sprint
• Updated daily
• May go up before going down
• Intended to facilitate team self-organization
• Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration
• Seemed like a good idea in the early days of Scrum, but in practice often misused as a management report, inviting intervention. The Scrum Master should discontinue use of this chart if it becomes an impediment to team self-organization.

 

25020015010050024-Jul 26-Jul28-Jul30-Jul 1-Aug 3-Aug5-Aug7-Aug 9-Aug 11-Aug 13-Aug

Figure 10: Sprint Burndown Chart

 

 

Product / Release Burndown Chart (optional)

• Tracks the remaining Product Backlog effort from one Sprint to the next
• May use relative units such as Story Points for Y axis
• Depicts historical trends to adjust forecasts

Acme Rocket Sled Enhanced Product Burndown

Projected completion in 1 – 5 sprints

 

• The product capabilities completed during the Sprints
• Brought to a usable, releasable state by the end of each Sprint
• Released as often as the Product Owner wishes
• Inspected during every Sprint Review

 

400

 

7/5/06
7/21/06
8/14/06
8/29/06
300

 

Effort units: story points
9/14/06
9/29/06
10/17/06
200

 

11/2/06
11/19/06
100

 

12/4/06
12/18/06
0

 

1/1/07
-100

 

-200

 

-300

 

-400

 

 

-500

 

 

123

 

4567

 

 

891011

 

 

(12) (13) (14) (15) (16) (17)

 

Sprint — Average Velocity: 47.36 story points/sprint

Effort Remaining Backlog w/ unestimated items Velocity Trendline Work Added/Removed Trendline New Baseline

Figure 11: A Release Burndown Chart variation popularized by Mike Cohn.5 The red line tracks PBIs completed over time (velocity), while the blue line tracks new PBIs added (new scope discovery). The intersection projects release completion date from empirical trends.

 

5 Agile Estimation and Planning, Cohn, Addison Wesley (2006)