Scrum
Deliver a product increment every 2 weeks. Ken Schwaber and Jeff Sutherland's agile framework for structuring development through iterative sprints.
Description
Scrum is an agile framework created by Ken Schwaber and Jeff Sutherland in 1995 that organizes product development into short cycles called sprints (2 to 4 weeks), with defined roles (Product Owner, Scrum Master, Developers), structured events, and a clear goal: to deliver a functional, potentially shippable product increment at the end of each sprint. Its purpose: to enable teams to deliver value continuously, predictably, and adaptively. Schwaber and Sutherland first presented Scrum at the OOPSLA conference in 1995, drawing inspiration from the article "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka (Harvard Business Review, 1986), which compared high-performing product teams to a rugby scrum. The Scrum Guide, the regularly updated reference document (latest version: 2020), fits in 13 pages. Scrum works like a four-stroke engine: Sprint Planning defines the what and the how, the Daily Scrum synchronizes the team in 15 minutes, the Sprint Review shows what was built to stakeholders, and the Sprint Retrospective improves the process. The Product Owner manages the Product Backlog (the ordered list of everything the product could contain), the Scrum Master facilitates the process and removes impediments, and the Developers commit to a Sprint Goal and self-organize to achieve it. What sets Scrum apart from other agile approaches is the non-negotiable sprint timebox: scope can change, but the duration stays fixed. This time constraint forces the prioritization decisions that teams avoid when the horizon is unclear. With over 87% of agile teams using Scrum or a derivative according to the State of Agile Report, it is the most widely adopted agile framework in the world.
Objectives
- Prioritize work
- Structure development
- Improve team collaboration
Used by
- -Spotify (used Scrum as the foundation for its organizational model of squads, tribes, and chapters)
- -Google (applies Scrum across many product teams, notably for the development of Android and Google Cloud)
- -Airbnb (uses Scrum to structure platform development and synchronize its distributed product teams)
Advantages
- Predictable and regular delivery. The fixed-length sprint creates a rhythm stakeholders learn to anticipate, reducing "when is it ready?" questions by 80%.
- Fast and continuous feedback. Each Sprint Review exposes the increment to users and stakeholders, correcting trajectory every 2 weeks instead of every 6 months.
- Lightweight framework documented in 13 pages. The Scrum Guide is the most concise and accessible agile framework, applicable from the first week.
- Suited to teams of all sizes. Works for a 5-person team as well as a 500-person organization (via Scrum@Scale or SAFe).
Limitations
- Requires a Product Owner with real decision-making power. If the PO must ask a committee for approval on every prioritization, Scrum becomes a bottleneck instead of an accelerator.
- Less suited to maintenance or support teams. 2-week sprints with a fixed scope are poorly suited to teams managing a continuous flow of incidents. Kanban is often more appropriate.
- Risk of "Scrum but...". Teams that adopt the ceremonies without the principles (self-organization, commitment, transparency) practice agile theater that generates frustration and disillusionment.
- The Sprint can create artificial pressure. If the Sprint Goal is systematically too ambitious, the team accumulates technical debt to "finish on time", which destroys quality in the medium term.
How to apply Scrum
- 1
Build the Scrum team
A Scrum team consists of a Product Owner (responsible for the what), a Scrum Master (responsible for the how), and Developers (responsible for delivery). The ideal size is 5 to 9 people total. Beyond that, communication degrades. The Product Owner is a single person, not a committee. If no one has the authority to prioritize the backlog, Scrum will not work. Output: Scrum team formed with assigned roles.
- 2
Create and order the Product Backlog
The Product Owner creates an ordered list of everything the product must contain: features, bugs, improvements, technical debt. Each item should be expressed in terms of user value. Items at the top of the backlog are detailed and ready for development; those at the bottom are rough ideas. The backlog is never frozen and evolves with each sprint. Output: initial Product Backlog ordered by value.
- 3
Plan the first sprint (Sprint Planning)
The team meets to define the Sprint Goal and select the backlog items to develop. The Sprint Planning duration is proportional to the sprint length: 4 hours max for a 2-week sprint. The Developers break each item into tasks and estimate whether the whole is achievable within the sprint. Output: Sprint Backlog with defined Sprint Goal.
- 4
Execute the sprint with Daily Scrums
During the sprint, the Developers work on Sprint Backlog items. Every day, the team synchronizes in 15 minutes (Daily Scrum): what did I do, what will I do, what is blocking me? The Scrum Master removes obstacles. No scope change is imposed during the sprint: if an urgent item appears, it enters the next sprint (unless the Product Owner decides to cancel the current sprint). Output: product increment under construction.
- 5
Present the increment in Sprint Review
At the end of the sprint, the team presents the completed increment to stakeholders. This is not a PowerPoint; it is a working demo. Stakeholders give their feedback, and the Product Owner updates the backlog accordingly. The Sprint Review is an inspection of the product, not a sign-off. Output: stakeholder feedback integrated into the backlog.
- 6
Improve the process in Sprint Retrospective
After the Review, the team meets privately to inspect its own functioning. What went well? What can be improved? The team commits to 1 to 3 concrete improvements for the next sprint. A retrospective without concrete action is a waste of time. Output: 1 to 3 committed process improvements.
- 7
Iterate sprint after sprint
Each sprint restarts the cycle: Planning, Daily Scrums, Review, Retrospective. The Product Owner continuously refines the backlog (refinement) so that the next 2 to 3 sprints have sufficiently detailed items. The fixed sprint cadence creates a predictable rhythm that stakeholders learn to respect. Output: continuous delivery of increments each sprint.
- 8
Measure and adjust velocity
After 3 to 5 sprints, the team has a stable velocity (number of points or items delivered per sprint). This velocity allows you to project realistic delivery dates and calibrate future commitments. Never compare velocity between teams: it is specific to each team and only meaningful internally. Output: velocity measured and used for planning.