Scrum Basics

What Is Scrum?

Scrum is an agile project management framework. The agile approaches to product development are conceptual frameworks for developing new products that seek to minimize risk and maximize value by working in time-boxed iterations and emphasizing working product as the primary measure of success. It uses an empirical approach—rather than predictive—to manage risk in a project. Scrum is ideally suited for projects with moderate- to high-risk that are likely to experience emerging requirements.

Scrum Roles


  • Facilitates (not leads) Scrum process by resolving impediments and encouraging team self-organization
  • Protects team from undue stakeholder influence and pressure
  • Promotes healthy Scrum attitudes and behaviors throughout the organization

Product Owner

  • Responsible for the product vision and for managing return on investment
  • Continually re-prioritizes Product Backlog based on organizational goals
  • Considers stakeholder interests
  • Has final say on priority of requirements

Scrum Development Team

  • Self-organized and cross-functional
  • Responsible for developing the technical solution
  • Determines how much work they can commit to each sprint

Scrum Artifacts

Product Backlog

  • Prioritized/ordered list of requirements requested from the team by the Product Owner
  • Managed and reprioritized as necessary by Product Owner
  • Visible to those inside and outside the Scrum team

Product Backlog Item (PBI)

  • Short description of functionality for a given product
  • May also be referred to as a requirement or user story (or simply “story”)
  • Clearly indicates under what functionality is required to call the PBI “done”

Sprint Backlog

  • Lists the PBIs committed to by the team for a given sprint
  • Always visible to the team
  • Referenced during the Daily Scrum

Sprint Burndown Chart

  • Tracks the amount of work remaining in a sprint versus time remaining.  May be tracked in hours, number of tasks or story points
  • Updated daily
  • Often misused as a management report, leading to undue stakeholder intervention. The sprint burndown is primarily a tool for the Scrum team, Product Owner and ScrumMaster

Scrum Meetings

Sprint Planning Meeting

  • Occurs at the beginning of each sprint
  • The Product Owner brings a prioritized product backlog to this meeting
  • The Team determines which PBIs they can commit to based on the amount of work they have successfully delivered in previous sprints
  • The committed PBIs are moved from the Product Backlog to the Sprint Backlog
  • To commit confidently, the team may also estimate, break the work out into tasks and begin design and planning

Daily Scrum

  • A short meeting—about 15 minutes—that occurs daily throughout the sprint
  • Each team member shares progress, daily goal, and impediments for the purpose of work coordination
  • Often held standing at a task board in order to encourage active team collaboration and timely meeting completion

Sprint Review Meeting

  • Occurs at the end of each sprint
  • The team presents the working product increment (using live presentation to demonstrate functionality) to the Product Owner for approval
  • The Product Owner approves the items s(he) considers “done” (i.e., shippable).  Items may also be rejected, upon which they are returned to the product backlog for further work
  • At the Product Owner’s discretion, stakeholders may attend this meeting in order to review product progress and voice any necessary concerns/adjustments
  • Stakeholder feedback may be captured as PBIs at this time and are transferred to the Product Backlog to be prioritized by the Product Owner

Sprint Retrospective Meeting

  • Occurs at the end of each sprint
  • Team inspects and adapts behavior for future sprints
  • ScrumMasters may choose to facilitate this meeting through activities such as silent writing, timelines, open discussion and satisfaction histograms

Backlog Refinement Meeting

  • Occurs a few days before sprint planning
  • Also known as Backlog Grooming, Backlog Maintenance, or Story Time
  • Goal of the meeting is to improve the product backlog.  Activities may include writing new user stories, breaking down stories that are too large or vague, estimation, clarifying requirements with stakeholders, etc.