The document provides a checklist of core Scrum practices and recommended but not required practices. It identifies the following as central to Scrum: delivering working software every sprint, delivering what the business needs most, and having a process that continuously improves. It also lists practices such as having a product backlog, sprint planning meetings, daily scrums, and retrospectives as important to Scrum. The checklist notes that while most recommended practices will be needed, teams should experiment with different approaches.

1. The bottom line Core Scrum the unofficial
If you achieve these you can ignore the
rest of the checklist. Your process is fine.
These are central to Scrum. Without these
you probably shouldn’t call it Scrum. Scrum Checklist
Delivering working, tested Retrospective happen after
software every 4 weeks or less every sprint
Results in concrete Henrik Kniberg
Delivering what the business
improvement proposals
needs most
Some proposals actually Recommended but not always necessary
Process is continuously get implemented Most of these will usually be needed, but not always all of them. Experiment!
improving
Whole team + PO
Team has all skills needed to PBL items are broken into
participates
bring backlog items to Done tasks within a sprint
Clearly defined product owner PO has a product backlog Team members not locked into
(PO) (PBL) Sprint tasks are estimated
specific roles
PO is empowered to Top items are prioritized Iterations that are doomed to Estimates for ongoing tasks
prioritize by business value fail are terminated early are updated daily
PO has knowledge to Top items are estimated
prioritize PO has product vision that is in
sync with PBL Velocity is measured
PO has direct contact with Estimates written by the
team team PBL and product vision is highly All items in sprint plan have
visible an estimate
PO has direct contact with Top items in PBL small
stakeholders enough to fit in a sprint Everyone on the team PO uses velocity for
participates in estimating release planning
PO speaks with one voice PO understands purpose
(in case PO is a team) of all backlog items PO available when team is Velocity only includes
estimating items that are Done
Team has a sprint backlog Have sprint planning meetings Estimate relative size (story Team has a sprint burndown
points) rather than time chart
Highly visible PO participates
Whole team knows top 1-3 Highly visible
impediments
Updated daily PO brings up-to-date PBL
SM has strategy for how to Updated daily
fix top impediment
Owned exclusively by the Whole team participates
team SM focusing on removing Daily Scrum is every day, same
impediments time & place
Results in a sprint plan
Escalated to management PO participates at least a
Daily Scrum happens
Whole team believes plan when team can’t solve few times per week
is achievable
Whole team participates Team has a Scrum Master (SM) Max 15 minutes
PO satisfied with
Problems & impediments priorities
Each team member knows
are surfaced SM sits with the team
what the others are doing
Timeboxed iterations
Demo happens after every Iteration length 4 weeks or Scaling Positive indicators
sprint less
These are pretty fundamental to any Leading indicators of a
Shows working, tested Scrum scaling effort. good Scrum implementation.
Always end on time
software
You have a Chief Product
Feedback received from Team not disrupted or Having fun! High energy level.
Owner (if many POs)
stakeholders & PO controlled by outsiders
Dependent teams do Scrum of Overtime work is rare and
Team usually delivers
Scrums happens voluntarily
Have Definition of Done (DoD) what they committed to
Dependent teams integrate Discussing, criticizing, and
DoD achievable within within each sprint experimenting with the process
Team members sit together
each iteration
PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
Team respects DoD Max 9 people per team
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)