Three roles, ceremonies, artifacts, best practices

Scrum is a simple framework for product development and team improvement. At its basis, all it does is define three roles, three ceremonies, and three artifacts. There are three related best practices that are good to use, but that are not part of the definition of Scrum. This is a super-small summary of the four threes, based on Dan Mezick's Scrum-in-30-minutes presentation.

Scrum's three roles

• Product Owner: owns and prioritizes the product backlog
  
• Scrum Master: facilitates the Scrum process
  
• Team: delivers a working product in increments
  

Scrum's three ceremonies

• Sprint planning meeting: review the backlog, review backlog estimates, pull stories from backlog, and make a sprint commitment
  
• Daily scrum: 15 minutes at the same time every day. What did you get done? What will you get done? What impediments are preventing you from getting things done?
  
• Sprint review meeting
• Part 1: demo
• Part 2: retrospective. How can the team accelerate?
  

Scrum's three artifacts

• Product backlog: list of user stories, prioritized by business value
  
• Sprint backlog: pulled from the product backlog, the list of stories that the team has committed to delivering at the end of the current sprint
  
• Burndown chart
• Sprint burndown: task hours completed toward this sprint's commitment
• Product burndown: story points completed toward some product release target
  

Three best practices

• User stories: As a TYPE-OF-USER I want SOME-GOAL [so that SOME-REASON]. E.g., As an end user I want the app to work with my BlackBerry Enterprise Server configuration so that I can listen to audiobooks regardless of the BES configuration.
  
• Planning poker: a fun, efficient way to estimate user stories and tasks, with the side effect that team members develop a shared understanding of each user story and task
  
• Scrum board: an information radiator, including at least the task board for this sprint's commitment. The minimum swim lanes are Committed, In Progress, and Done, or, more generally,To Do, Doing, and Done.
  

Sources

• Dan Mezick, at Agile Boston meetings, and summarized on the Agile Boston web site
  
• Mike Cohn's user stories template