Scrum at a Glance
Framework Overview
The Scrum Framework
Scrum is built on empirical process control — three pillars: Transparency, Inspection, and Adaptation. It organises work into fixed-length iterations called Sprints (max. 4 weeks), each delivering a potentially shippable increment.
3 Pillars: Transparency — everyone shares the same understanding of work and standards. Inspection — frequent checks of progress toward the goal. Adaptation — adjusting the process when deviations are found. These underpin all Scrum events and artifacts.
Roles & Accountabilities
Product Owner
"customer representative"
- Develops and communicates the product goal
- Owns and prioritises the Product Backlog
- Determines release dates and content
- Accepts or rejects completed work
Scrum Master
"servant leader"
- Ensures the Scrum process is followed
- Removes impediments for the team
- Facilitates Scrum events (time-boxing)
- Keeps Scrum artifacts up to date
Developer
"not necessarily a software dev"
- Responsible for Sprint Backlog items
- Ensures quality — upholds Definition of Done
- Keeps the Sprint Goal in focus
- Self-organising, cross-functional
The Scrum Team
Team Structure
Characteristics
- Usually max. 10 members
- No sub-teams — clear roles only
- Self-organising — decides how to do the work
- Cross-functional — all skills needed are present
Accountability summary
- PO → maximises product value
- SM → maximises team effectiveness
- Developers → deliver the Increment
- All share responsibility for Scrum process
Artifacts
Artifact 1
Product Backlog
The single, ordered list of everything needed in the product.
- Single — one backlog per product
- Transparent — visible to all
- Current — continuously refined
- Ordered — PO orders by value
- Contains the Product Goal and all Product Backlog Items
Artifact 2
Sprint Backlog
The work selected for the current Sprint plus the plan to deliver it.
- Contains the Sprint Goal
- Selected items from the Product Backlog
- Execution plan for Developers
- Large items broken into smaller tasks
- Visualised on a task board: open / in progress / done
Artifact 3
Increment
A concrete, usable step toward the Product Goal — delivered every Sprint.
- One or more increments per Sprint
- Must meet Definition of Done
- Usable regardless of whether the PO releases it
- Each increment builds on all prior ones
Concept
Definition of Done (DoD)
A shared understanding of what "complete" means for any Increment. Creates transparency and ensures consistent quality across the team.
Key rules
- If an item doesn't meet DoD → back to Product Backlog
- Cannot be presented at Sprint Review without meeting DoD
- Developers are required to conform to it
Org vs. team scope
- If org-wide standard exists → all teams must follow it as minimum
- If no standard → Scrum Team creates their own DoD
- Multiple teams on same product → must share one DoD
Product Backlog · Structure
Requirement Hierarchy
Backlog items are structured from broad themes down to concrete, testable stories.
01
Theme
broad strategic area
↓
02
Feature
concrete functionality
↓
03
User Story
specific value for a user group
↓
04
Task
implementation sub-step (in Sprint Backlog)
Product Backlog Refinement: A continuous process — not a formal Sprint event. Owned by the Product Owner. Involves adding new requirements, breaking items down, and re-estimating effort.
Events
The Sprint
Sprint — Heart of Scrum
A fixed-length iteration (max. 4 weeks) in which a usable Increment is created. Sprints follow immediately after one another — no gaps.
Rules
- Requirements are fixed during a Sprint
- No breaks between Sprints
- Max. 4 weeks; shorter is often better
- Contains all 4 recurring meetings
Time-boxing
- Key tool for discipline and focus
- Scrum Master is responsible for enforcement
- Limits scale with Sprint duration (shown below)
- Prevents scope creep within the event
All 5 Events
Event Reference
| Event | Participants | Time-box (1-month Sprint) | Purpose |
|---|---|---|---|
| Sprint | Entire Scrum Team | ≤ 4 weeks | Container for all other events; produces an Increment |
| Sprint Planning | Dev + PO + SM | max. 8 h | Select Product Backlog Items → Sprint Backlog; set Sprint Goal; plan execution |
| Daily Scrum | Dev + SM | max. 15 min | Sync on progress since last Daily, plan until next, surface impediments |
| Sprint Review | Scrum Team + stakeholders | max. 4 h | Demo Increment to PO & client; discuss and adapt Product Backlog |
| Sprint Retrospective | Team + SM | max. 3 h | Inspect team process; identify improvements; commit to changes next Sprint |
User Stories & Acceptance Criteria
Format
User Story Formula
As [who] I want [what] so that [why / benefit].
Each story must specify a distinct target group ("who"), a concrete functionality ("what"), and the value delivered ("why"). Examples:
As a busy professional, I want a large selection of different workout durations, so that I can fit exercise into my daily schedule.
Acceptance criterion: Filter for at least 3 different workout durations with videos displayed per selection.
As a student, I want as many bodyweight exercises as possible, so that I don't need to buy expensive equipment.
Acceptance criterion: At least 50% of workouts require no equipment; tagged "no equipment" in filters.
As a beginner, I want short videos with easy exercises, so that I have a gentle entry point into fitness.
Acceptance criterion: Videos max. 5 min, labelled "beginner-friendly", with clear on-screen instructions.
Concept
Acceptance Criteria
Conditions that must be met for a User Story to be considered correctly and completely implemented.
Purpose
- Makes the Definition of Done concrete per story
- Enables objective testing of completion
- Agreed between PO and Developers during refinement
- Drives the Sprint Review demo
Good criteria are…
- Testable — yes or no, not "mostly"
- Specific — concrete numbers or behaviours
- Agreed — not imposed unilaterally
- Minimal — only what's needed, not a full spec
Quality checklist
INVEST — Guidelines for Good User Stories
I
Independent
Can be developed and delivered without depending on another story
N
Negotiable
Not a contract — details can be discussed and adjusted
V
Valuable
Delivers clear value to a specific user or the business
E
Estimatable
Team can estimate the effort required
S
Small
Fits within a single Sprint — split if too large
T
Testable
Acceptance criteria exist to verify it's done
Estimation — Story Points & Planning Poker
Concept
Story Points
Relative measure of effort, complexity and uncertainty — not time.
- Compare backlog items relative to each other
- Not an absolute unit (not hours or days)
- Velocity = story points completed per Sprint
- Enables burn-down charts to visualise progress
- Teams calibrate around a shared reference story
Concept
Velocity & Burn-Down
- Velocity: stabilises after a few Sprints — use for forecasting
- Burn-down chart: remaining story points over time
- Ideal line vs. actual — shows if team is on track
- Velocity is team-specific — don't compare across teams
- Improves predictability over time
Technique
Planning Poker
A consensus-based estimation technique. Each team member independently estimates, then all reveal simultaneously — divergence triggers discussion.
Process
- Team selects a medium-sized reference story first
- PO reads out the story to be estimated
- Each member picks a card face-down
- All reveal simultaneously
- Extreme values discuss their reasoning
- New round until consensus
Why simultaneously?
- Prevents anchoring bias from early reveals
- Everyone must commit to an independent estimate
- Forces structured discussion on outliers
- The process surfaces hidden complexity
Card values (modified Fibonacci — gaps reflect estimation uncertainty at scale):
0
1
2
3
5
8
13
20
40
100
∞
?
☕
Card meanings: 0 = too trivial to estimate. ∞ = too large, must be split. ? = not enough information to estimate. ☕ = team needs a break. The Fibonacci-like sequence intentionally has larger gaps at the top — precision at high complexity is meaningless.
How It All Connects
Synthesis
How It All Connects
01
The Product Owner builds and orders the Product Backlog — the single source of truth for all required work, expressed as User Stories with acceptance criteria.
02
Sprint Planning selects items from the Product Backlog into the Sprint Backlog. The team commits to a Sprint Goal — the why of the Sprint.
03
During the Sprint, Daily Scrums keep the team synchronised. The Scrum Master removes impediments and enforces time-boxes.
04
The Sprint produces an Increment meeting the Definition of Done. The Sprint Review demos it to stakeholders; the Retrospective improves the team process.
05
Story Points and Planning Poker give the team a shared, bias-free way to estimate relative effort — feeding into velocity and long-term forecasting via burn-down charts.
Exam Preparation
Definitions · memorise these
Key Terms at a Glance
Scrum
Agile framework based on empirical process control (transparency, inspection, adaptation). Works in fixed Sprints with 3 roles, 3 artifacts, 5 events.
Sprint
Fixed-length iteration (max. 4 weeks) producing a usable Increment. Sprints are consecutive — no gaps or pauses between them.
Product Backlog
Single, ordered list of all required work. Owned by the PO. Properties: single, transparent, current, ordered.
User Story
"As [who] I want [what] so that [why]." Describes concrete value for a specific user group. Must follow INVEST criteria.
Story Points
Relative measure of effort/complexity — not time. Used to compare backlog items. Velocity = story points per Sprint.
Definition of Done
Shared checklist defining "complete" for any Increment. Items not meeting DoD cannot be released or presented at Sprint Review.
Velocity
Number of story points a team completes per Sprint. Stabilises over time; used for forecasting. Team-specific — not comparable across teams.
Time-boxing
Strict enforcement of maximum event durations. Scrum Master's responsibility. Prevents scope creep and keeps cadence predictable.
Strategy
Exam Tips
3 · 3 · 5
Scrum has exactly 3 roles, 3 artifacts, and 5 events. Know them all by name — questions often ask you to list or classify them.
Time-boxes per event
Sprint Planning 8h, Daily 15min, Review 4h, Retro 3h — all for a 1-month Sprint. Scale proportionally for shorter Sprints.
User story formula
Always use: "As [who] I want [what] so that [why]." Three distinct target groups = three distinct "who" values. Don't reuse.
AC vs. DoD
Acceptance Criteria are per story — specific conditions agreed for that story. Definition of Done applies to all Increments — it's the team-wide quality bar.
Story points ≠ hours
Story points are relative and team-specific. Never state them as hours. Velocity is the mechanism that translates points into time forecasts.
Retrospective vs. Review
Review = inspect the product (Increment) with stakeholders. Retrospective = inspect the process (how the team worked). Common mix-up in exams.
Practice questions · click to reveal
Possible Exam Questions
Name the 3 roles, 3 artifacts and 5 events of Scrum. ▶
Roles: Product Owner, Scrum Master, Developer.
Artifacts: Product Backlog, Sprint Backlog, Increment.
Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Artifacts: Product Backlog, Sprint Backlog, Increment.
Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
What are the three pillars of empirical process control in Scrum? ▶
Transparency — shared understanding of work and standards. Inspection — frequent review of progress and artifacts. Adaptation — adjusting the process whenever deviations are found. All Scrum events are opportunities for inspection and adaptation.
What is the difference between Product Backlog and Sprint Backlog? ▶
The Product Backlog is the complete, ordered list of all required work for the product — maintained by the PO, always evolving. The Sprint Backlog is the subset selected for one Sprint, plus the Sprint Goal and the Developers' plan — owned by the Developers and fixed for the Sprint duration.
What is the difference between Sprint Review and Sprint Retrospective? ▶
The Sprint Review inspects the Increment — the team demos what was built to the Product Owner and stakeholders; the Product Backlog may be adapted. The Sprint Retrospective inspects the team process — how the team worked — and identifies improvements to implement in the next Sprint.
What is the correct format for a User Story and what does INVEST stand for? ▶
Format:
INVEST: Independent, Negotiable, Valuable, Estimatable, Small, Testable. These criteria ensure stories are well-formed, deliverable and verifiable.
As [who] I want [what] so that [why].INVEST: Independent, Negotiable, Valuable, Estimatable, Small, Testable. These criteria ensure stories are well-formed, deliverable and verifiable.
What are story points and what is velocity? ▶
Story points are a relative measure of effort, complexity and uncertainty — they are not hours or days. They allow backlog items to be compared to each other. Velocity is the number of story points a team completes per Sprint. It stabilises over time and is used for forecasting — but is team-specific and should not be compared across teams.
Explain the Planning Poker process. Why are cards revealed simultaneously? ▶
The PO describes a story; each team member independently selects a card representing their estimate relative to the reference story, then all reveal at the same time. Those with extreme values explain their reasoning, and rounds continue until consensus.
Simultaneous reveal prevents anchoring bias — if one person reveals first, others tend to adjust toward that value rather than giving an independent estimate.
Simultaneous reveal prevents anchoring bias — if one person reveals first, others tend to adjust toward that value rather than giving an independent estimate.
What is the Definition of Done and why does it matter? ▶
The Definition of Done is a shared checklist defining what "complete" means for any Increment. It creates transparency by ensuring everyone agrees on quality standards. If an item doesn't meet the DoD it cannot be presented at the Sprint Review and returns to the Product Backlog. If an org-wide DoD exists, teams must use it as a minimum; otherwise, the Scrum Team defines its own.
What does the Product Backlog hierarchy look like and what is each level? ▶
Theme — the broad strategic topic or area.
Feature — concrete functionality within that theme.
User Story — specific value for a target user group, written in the "As / I want / so that" format.
Task — small implementation steps broken out of a User Story, tracked in the Sprint Backlog.
Feature — concrete functionality within that theme.
User Story — specific value for a target user group, written in the "As / I want / so that" format.
Task — small implementation steps broken out of a User Story, tracked in the Sprint Backlog.
What are the maximum time-boxes for each Scrum event (1-month Sprint)? ▶
Sprint: max. 4 weeks (the container for all other events).
Sprint Planning: max. 8 hours.
Daily Scrum: max. 15 minutes.
Sprint Review: max. 4 hours.
Sprint Retrospective: max. 3 hours.
For shorter Sprints, all time-boxes scale proportionally. The Scrum Master is responsible for enforcing them.
Sprint Planning: max. 8 hours.
Daily Scrum: max. 15 minutes.
Sprint Review: max. 4 hours.
Sprint Retrospective: max. 3 hours.
For shorter Sprints, all time-boxes scale proportionally. The Scrum Master is responsible for enforcing them.