Scrum
/skrʌm/ · Noun · Development · Origin: 1995
Definitions
Scrum is an agile framework for managing and completing complex projects, most commonly used in software development. It organizes work into fixed-length iterations called sprints, typically lasting two weeks, during which the team commits to completing a set of prioritized tasks from the product backlog. Scrum defines three roles: the Product Owner, who prioritizes work based on business value; the Scrum Master, who facilitates the process and removes impediments; and the Development Team, which is self-organizing and cross-functional. Key ceremonies include Sprint Planning (deciding what to build), the Daily Standup (a short meeting to synchronize progress and surface blockers), the Sprint Review (demonstrating completed work to stakeholders), and the Sprint Retrospective (reflecting on how to improve). Scrum emphasizes transparency, inspection, and adaptation. It does not prescribe engineering practices but provides a framework for iterative delivery that helps teams respond to changing requirements, reduce risk, and deliver working software incrementally.
In plain English: A popular way to organize software work into 2-week chunks called 'sprints' with daily check-in meetings — works well when done right, annoying when done wrong.
Origin Story
A rugby metaphor for software teams
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published a paper in the Harvard Business Review called 'The New New Product Development Game.' They compared high-performing product teams to rugby — specifically, the way the entire team moves down the field as a unit, passing the ball back and forth, in a formation called a scrum.
Jeff Sutherland and Ken Schwaber independently picked up this rugby metaphor in the early 1990s and formalized it into a software development framework. Sutherland implemented it at Easel Corporation in 1993, and Schwaber presented it at OOPSLA in 1995.
The rugby metaphor persists in Scrum terminology: sprints, scrums, and the idea that the team moves together rather than passing work sequentially from person to person. Whether the framework lives up to its aspirations is one of software's most heated ongoing debates.
Coined by: Jeff Sutherland & Ken Schwaber (framework); Takeuchi & Nonaka (metaphor)
Context: OOPSLA Conference, 1995
Fun fact: Takeuchi and Nonaka's original paper studied Honda, Canon, and Fuji-Xerox product teams — none of them were software companies.