Scrum Framework
Scrum is an Agile framework using fixed-length sprints, defined roles (Product Owner, Scrum Master, Developers), and ceremonies to deliver incremental value.
What is the Scrum framework?
Scrum is the most widely used Agile framework. It organises work into fixed-length iterations called sprints (1-4 weeks, most commonly 2 weeks) and defines roles, events, and artefacts to enable empirical process control.
Scrum is based on three pillars: Transparency (everyone sees the real state), Inspection (regularly examine artefacts and progress), and Adaptation (adjust when inspection reveals deviation).
Roles
Product Owner (PO)
- Owns the Product Backlog - the ordered list of work
- Responsible for maximising the value of the product
- Clarifies requirements; decides what gets built and in what order
- Single point of authority for product decisions - no committee PO
Scrum Master (SM)
- Serves the team by removing impediments
- Coaches the team on Scrum practices
- Facilitates events; protects the team from external interruptions
- Not a project manager - does not assign tasks or track individual output
Developers (the Team)
- Cross-functional - all skills needed to deliver are within the team
- Self-organising - team decides how to do the work
- Typically 3-9 people ("two-pizza rule")
- Accountable for delivering a Done increment each sprint
Events (Ceremonies)
| Event | When | Duration (2-wk sprint) | Purpose |
|---|---|---|---|
| Sprint Planning | Start of sprint | <=8 hours | Select and plan sprint work |
| Daily Scrum | Every day | 15 min | Synchronise and surface blockers |
| Sprint Review | End of sprint | <=4 hours | Inspect increment, update backlog |
| Sprint Retrospective | End of sprint | <=3 hours | Inspect process, plan improvements |
Sprint Planning
Team answers: what can be delivered this sprint? How will the work be done? The PO presents top backlog items; team pulls items they can commit to (never pushed). Result: a Sprint Goal and Sprint Backlog.
Daily Scrum
Not a status meeting - a coordination meeting. Each developer: what did I do yesterday that helps the sprint goal? What will I do today? Any impediments? Keep to 15 min; sidebar discussions after.
Sprint Review
Inspect the increment and adapt the backlog. Team demonstrates working software to stakeholders. PO reviews what's done vs not done. Feedback incorporated into the backlog.
Sprint Retrospective
"How can we improve our process?" Inspect people, relationships, process, and tools. Identify 1-3 actionable improvements for the next sprint.
Artefacts
- Product Backlog: ordered list of all desired work. Items are Product Backlog Items (PBIs) or User Stories. Refined continuously.
- Sprint Backlog: the subset of backlog pulled into the current sprint + the plan for delivering it.
- Increment: the sum of all completed work - must be useable and meet the Definition of Done.
Definition of Done (DoD)
The shared understanding of what "done" means. Typically includes: code complete, unit tests passing, integration tests passing, code reviewed, deployed to staging, documentation updated. The DoD prevents the team from shipping half-finished work.
Velocity
A measure of how much work (story points) the team completes per sprint. Used for forecasting, not for comparing teams or as a performance target. Velocity is a historical planning tool - not a productivity metric.
Common Pitfalls
- Mini-waterfalls: breaking sprint work into design -> dev -> test phases within the sprint instead of delivering incrementally
- Sprint scope creep: adding items mid-sprint outside emergency situations
- Ignoring retrospective actions: no follow-through -> retros become performative
- Proxy PO: real decisions require approvals from someone above the PO -> blocks the team
Interview Angle
Scrum is frequently asked in senior engineering interviews - interviewers want to know if you can work effectively in Agile teams. Key points: roles and their authorities (PO orders the backlog, team self-organises), the difference between Sprint Review (product feedback) and Retrospective (process improvement), and the DoD as the quality gate. Distinguish velocity (planning tool) from performance metric. Show that you understand why Scrum works - empirical process control and fast feedback loops.