Scrum
A lightweight framework for developing, delivering, and sustaining complex products through short, iterative cycles called Sprints.
What it means
Scrum is defined by the Scrum Guide as a framework, not a methodology: it provides a minimal set of rules, roles, and events that teams fill in with their own practices. It is built on the three pillars of empiricism (transparency, inspection, adaptation) and the five values of commitment, focus, openness, respect, and courage.
A Scrum Team is small, cross-functional, and self-managing. It consists of a Scrum Master, a Product Owner, and Developers. There are no sub-teams or hierarchies inside it. The team works in Sprints, timeboxed periods of one month or less during which a usable Increment is created.
Scrum deliberately leaves implementation details open. It does not prescribe estimation techniques, engineering practices, or specific ceremonies beyond the five events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) and three artifacts (Product Backlog, Sprint Backlog, Increment).
Common mistakes
Because Scrum surfaces problems quickly through short feedback loops, it works best in domains with high uncertainty, where requirements change as the product is built and learned about.
Example
A five-person product team adopts Scrum to ship a mobile app: they run two-week Sprints, hold a Daily Scrum each morning, and inspect a working Increment at every Sprint Review.