Scrum Framework
A lightweight Agile framework for developing, delivering, and sustaining complex products. The most widely adopted Agile framework; the core of Course 5 of the Google PM Certificate.
Agile is the foundational philosophy and mindset; Scrum is the framework that materializes it.
The authoritative reference is the Scrum Guide at Scrumguides.org.
Scrum theory
Scrum is built on empiricism — the idea that knowledge comes from actual, lived experience. Empiricism rests on three pillars.
The 3 pillars
- Transparency — make significant aspects of work visible to those responsible for outcomes. Critical to team productivity.
- Inspection — timely checks toward a Sprint’s outcome to detect undesirable variances. More inspection → more improvement.
- Adaptation — adjust project, product, or processes to minimize further deviation. Includes immediate fixes and longer-term process changes.
The 5 values
- Commitment — personally committing to the Scrum Team’s goals
- Courage — doing the right thing and working on tough problems
- Focus — focusing on the Sprint’s work and the team’s overall goals
- Openness — being open about work and challenges
- Respect — respecting teammates’ opinions, skills, and independence
Scrum roles
Scrum teams are cross-functional and self-organizing. A delivery is the accomplishment of the entire team.
Scrum Master — building the thing fast
Promotes and supports the Scrum process; helps everyone understand and implement Scrum.
Responsibilities:
- Coach the team on Agile/Scrum practices, rules, and values
- Help manage the Product Backlog effectively
- Facilitate Scrum events
- Help remove blockers
- Prevent unhelpful interactions from outside the team
- Coach team members
Skills: organization, leadership, facilitation, coaching, stakeholder management.
The Scrum Master is not a traditional project manager — they focus on process, not scope.
Product Owner — building the right thing
Ensures the team is building the right product. Represents the customer and vision.
Responsibilities:
- Continuously maximize value delivered by the Scrum Team
- Help the team understand why their work matters
- Prioritize the Product Backlog
- Ensure the Backlog is visible and transparent to all
- Ensure the product fulfills customer needs
Traits: customer-focused, decisive, flexible, optimistic, available, collaborative.
Development Team — building the thing right
The people who do the work to build the product.
Traits: cross-functional, self-organizing, supportive, customer-oriented.
Scrum artifacts
Product Backlog
The single authoritative source for everything the team works on. Contains all features, requirements, and activities associated with deliverables to achieve the product goal.
Properties:
- Living artifact
- Owned and adjusted by the Product Owner
- Prioritized list of features
Each backlog item has: description, value, order, estimate.
Backlog refinement — keeping the Backlog described, estimated, and prioritized so the team can operate effectively. The team reviews it to ensure:
- It contains the right items (nothing missing, nothing obsolete)
- Items are prioritized by the PO (the “order” field)
- Top items are ready for delivery with clear acceptance criteria
- Items include estimates
See user-stories-and-invest for how backlog items are written.
Product Increment
What is produced after a given Sprint — a complete, tested, usable piece of the product that is potentially releasable. Each increment builds on previous ones and must meet the team’s Definition of Done.
Definition of Done (DoD)
The checklist for “done”:
- Code or solution reviewed by an independent peer
- Passes all testing requirements (security, performance, etc.)
- Documentation complete
- All user story acceptance criteria met
- Product Owner accepts the story
Scrum events
The Sprint
A fixed time period up to one month where a Scrum Team turns ideas into working value. The container for all other Scrum events. A new Sprint starts immediately after the previous one ends.
Sprint rules:
- No changes that threaten the Sprint Goal
- Quality standards must be maintained
- Backlog can be refined and scope clarified mid-sprint
- Only the Product Owner can cancel a Sprint (if the goal becomes irrelevant)
Purpose: predictability through regular inspection and adaptation; short cycles reduce risk and enable continuous learning.
Sprint Planning
The entire Scrum Team meets to confirm capacity (time and people) and plan the Sprint. Defines the Sprint Goal.
Daily Scrum
A 15-minute (or less) meeting every day of the Sprint. The Scrum Team synchronizes and prioritizes activities for the day.
Sprint Review
A meeting with the entire Scrum Team where the product is demonstrated to determine which aspects are finished. Covers:
- Exploration of what should be considered “done” in the product backlog
- Demonstration and inspection of the product
Sprint Retrospective
An essential meeting of up to 3 hours for the team to step back, reflect, and identify improvements in how they work together.
Pitfalls: overusing games/gimmicks; focusing only on negatives; changing processes too frequently.
Best practices: open-ended questions; support different communication styles (silent reflection, small groups); review performance, quality, communication, progress; reflect on Scrum values; balance problems with celebrating successes.
Scaled releases
- Releasable Product Increment — created every Sprint, fully functional and tested, may or may not be released
- Minimum Viable Product (MVP) — the smallest version of the product that delivers value and gathers feedback; may take multiple Sprints to build
- Key difference: an increment is a completed piece of work from a Sprint; an MVP is a strategic release composed of one or more increments
Progress tracking
- Burndown chart — measures time against work done and work remaining
- Velocity — how many points the team burns down in a given Sprint
- Progress can be tracked with charts, but decisions rely on real outcomes
Founding principles (rugby-inspired)
- Built-in instability — challenging goals create healthy tension
- Self-organizing teams — autonomy with minimal hierarchy
- Overlapping work — parallel effort, aligned pace
- Multi-learning — continuous learning through trial and error
- Subtle control — light structure with checkpoints
- Shared learning — team members support each other and expand skills
Application
Use Scrum when:
- The work is complex and not fully understood up front
- Customer needs are likely to evolve
- The team can work in cross-functional units of ~3–9 people
- You can establish a stable cadence
Don’t use Scrum (or don’t only use Scrum) when:
- Work is continuous-flow, unpredictable (consider kanban)
- You’re operating at scale requiring coordination across many teams (see scaling-agile-frameworks)
- The environment is extremely low-VUCA — waterfall may suffice
Connections
- agile-manifesto — underlying philosophy
- user-stories-and-invest — how backlog items are written
- value-roadmap — longer-term planning surrounding sprints
- kanban scaling-agile-frameworks
- course-5-agile-project-management