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







choose persistence strategy (Hibernate?)

write code (using test- driven




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


Forecasted PBIs


User login


Acceptance Criteria: ….




SSL enable


Acceptance Criteria: ….




Reset lost password


Acceptance Criteria: ….




Lock account af ter three attempts

Acceptance Criteria: ….



Tasks Not Started









update installation document





agree on best decidecode (using

algorithm for where totest-driven randomizing put the link development passwords)





screenshot exploratory

and text to testing user manual



updatemanual test

code (using migration (try to

test-driven tool tobreak in

development) include new with policy

row forinstalled)





update documents

Tasks In Progress










deploytesting (3

target inbrowsers) build.xml

Tasks Completed


determineget latest

requirements page layout JBoss for password (design)running policy




choosewrite code

persistence using test- exploratory strategy driventesting

(Hibernate?) development






analyzeget official

example config certificate install

filefrom I.T.certificate

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




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






Effort units: story points


























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



Icon for the Creative Commons Attribution 4.0 International License

Project Management Basics Copyright © by Sharon Blanchard is licensed under a Creative Commons Attribution 4.0 International License, except where otherwise noted.