The Scrum Framework in the Google PM Certificate: A Complete Breakdown
Scrum is the most popular Agile framework. If you're studying the Google PM Certificate (especially Course 5), you'll dive deep into Scrum: its roles, artifacts, and ceremonies. Scrum is also increasingly what companies want—job postings ask for "Scrum experience" more than ever. This article breaks down every piece of Scrum and shows you how it fits together to make teams deliver value iteratively.
What is Scrum? (Beyond the Name)
Scrum is a lightweight framework for managing product development iteratively. It's not a detailed process; it's a structure that teams adapt to their context. Core idea: break work into small, time-boxed sprints (usually 2 weeks); deliver a working increment each sprint; inspect and adapt based on feedback; repeat.
Named after rugby (a "scrum" is where the team packs together tightly to move the ball forward), the term reflects the idea of close collaboration and unified forward momentum.
The Three Pillars of Scrum
1. Transparency: Everyone sees the product backlog, sprint progress, blockers. Nothing is hidden.
2. Inspection: Regular review of progress (sprint review), process (sprint retrospective), and product (potentially shippable increment).
3. Adaptation: Based on inspection, the team adapts the product (backlog adjusts), the process (retro improvements), and the plan (velocity forecasts).
These three pillars are why Scrum works—you're constantly sensing and responding, not executing a fixed plan blindly.
The Three Scrum Roles
Product Owner (PO)
The PO represents the customer and business. They own the product vision and prioritize work. Responsibilities:
- Maintain and prioritize the product backlog
- Define requirements (user stories) clearly enough for the team to build
- Accept completed work in the sprint review
- Make trade-off decisions (scope vs. time)
The PO is not a committee. One person owns the backlog and makes decisions. This prevents design-by-committee.
Scrum Master (SM)
The Scrum Master facilitates Scrum practices. They don't manage the team; they coach the team on Scrum. Responsibilities:
- Facilitate all Scrum ceremonies (planning, standup, review, retro)
- Remove blockers (impediments) that prevent the team from progressing
- Protect the team from external distractions during sprints
- Coach the organization on Scrum values
This is NOT the traditional project manager role. The SM doesn't own scope, budget, or timeline. They own process health.
Development Team
The team builds the product. Characteristics:
- Cross-functional (developers, QA, designers, whoever is needed)
- Self-organizing (decides how to do the work, not micromanaged)
- Commits to sprint goals
- Accountable to deliver a working increment each sprint
Team size typically 5-9 people. Smaller teams are more efficient; larger teams harder to coordinate.
The Five Scrum Artifacts
1. Product Backlog
A prioritized list of everything the product needs: features, improvements, fixes, technical work. Lives in a tool (Jira, Azure DevOps, Trello, etc.). Owned by the Product Owner.
Example product backlog items (called "user stories"):
- "As a user, I want to reset my password so that I can access my account if I forget it"
- "As an admin, I need to see a report of user activity so I can track engagement"
- "As a user, I want the login page to load in under 2 seconds"
Each item has a description, acceptance criteria, and estimate (story points). The backlog is never "done"; it evolves as the product vision evolves.
2. Sprint Backlog
The subset of the product backlog selected for the current sprint. The team commits to completing this work. Items broken down into tasks with time estimates (hours or days).
Example: "Build password reset feature" (from product backlog) becomes sprint backlog items:
- Design password reset flow (4 hours)
- Build backend API (16 hours)
- Build frontend UI (8 hours)
- Test end-to-end (4 hours)
Sprint backlog is owned by the team (not the PO). The team can adjust tasks during the sprint to meet the sprint goal.
3. Product Increment
The working product that results from the sprint. Should be "potentially shippable"—if the team said "we're releasing today," they could. (They might not release; the PO might wait for more features. But technically, it's releasable.)
This is powerful: every sprint, you have a demo-able, working piece of product. No "big reveal" at the end.
4. Definition of Done (DoD)
Criteria for considering work "done." Not the same as "complete." Example DoD:
- Code written
- Code reviewed by peer
- Unit tests written and passing
- Integrated with main codebase
- Tested in staging environment
- Documentation updated
Every item in the sprint must meet the DoD to be called "done." This prevents "oh, we forgot to test that" discoveries.
5. Burndown Chart
A visual showing work remaining (vertical axis) vs. days in sprint (horizontal axis). As the team completes work, the line slopes downward (burns down). If the line is above the "ideal" trend, the team is behind. Below, they're ahead.
Burndown charts are powerful because they're visual and predictive. "If we keep this pace, will we finish the sprint on time?"
The Five Scrum Ceremonies (Time-Boxed Events)
1. Sprint Planning (4 hours for 2-week sprint)
At the start of the sprint, the team and PO plan together:
- PO presents prioritized backlog items
- Team asks clarifying questions
- Team selects items they can commit to (based on velocity)
- Team breaks items into tasks and estimates
- Team defines the sprint goal: "What do we want to accomplish?"
Commitment matters. The team is saying "We will deliver this. It's realistic based on our velocity."
2. Daily Standup (15 minutes, every day)
Quick sync. Each team member: "Yesterday I [accomplished]. Today I'll [work on]. I'm blocked by [blocker, if any]."
Purpose: surface blockers fast and keep team aligned. Not a status report to the boss; it's a team alignment.
3. Sprint Review (2 hours for 2-week sprint)
At the end of the sprint, the team demos completed work to stakeholders:
- "Here's what we built this sprint"
- Stakeholders give feedback
- Feedback goes into the product backlog for future sprints
This is NOT a status report meeting. It's a working demo. Stakeholders see the product, use it, react. This feedback shapes the next sprint.
4. Sprint Retrospective (1.5 hours for 2-week sprint)
The team reflects, without stakeholders:
- "What went well this sprint?"
- "What didn't go well?"
- "What will we change next sprint?"
Goal: continuous improvement of process. "We spent too much time in code review. Next sprint, let's pair program on risky features." "We're more productive when we all work in one timezone 9-5. Let's structure stand-up differently."
Retrospectives drive team learning.
5. Backlog Refinement (1-2 hours, ongoing, not in every sprint)
The PO and team review backlog items, clarify requirements, estimate story points. This happens continuously, not as a ceremony, but it's important. Well-refined backlog = smooth sprints.
Key Metrics in Scrum
Velocity: Average number of story points the team completes per sprint. "Our velocity is 35 points per sprint" means we expect to complete 35 points of work each sprint. Use this to forecast: if the backlog has 100 points, and velocity is 35/sprint, we'll need 3 sprints.
Sprint Goal: The overarching goal for the sprint. Not the same as "complete X, Y, Z items." Broader. Example: "Improve user onboarding" (multiple features might contribute).
Story Points: Relative size/complexity estimates for backlog items. Not hours (which change; points are relative). "This feature is about 5 points; that one is 8 points." Helps the team pick appropriately-sized work for a sprint.
Scrum vs. Scrum Master Certification
The Google PM Certificate teaches Scrum framework. If you want to go deeper, you can pursue Scrum Master certification (CSM from Scrum Alliance or other certifications). That requires a 2-day course + exam + experience. Google cert is the foundation; CSM is specialization.
Related reading: Compare Scrum/Agile to Waterfall and explore Kanban as an alternative to Scrum.
Next Steps
If you want a structured study companion, our Google PM Certificate Study Guide covers the full 6-course breakdown, a week-by-week study plan, and 50 practice questions with answer explanations—everything you need in one place.
For AI-powered tutoring, SimpuTech's Google PM Certificate study coach walks you through practice questions, explains concepts you're stuck on, and builds a custom study plan around your schedule. Try it free for 1 day.
Program details verified against grow.google/certificates/project-management as of March 2026. Pricing and course structure are subject to change—confirm current details before enrolling.