Scrum
Scrum is a lightweight framework for developing complex products in short, fixed-length iterations called Sprints. Created by Ken Schwaber and Jeff Sutherland in the 1990s and defined in the concise Scrum Guide, it is the most widely used agile framework in software development. Scrum does not prescribe engineering practices or tools; it defines a small set of accountabilities, events, and artifacts that make progress and problems visible, so a team can inspect and adapt frequently.
Scrum is easy to describe and hard to do well. Many teams adopt its meetings and vocabulary but miss its purpose: delivering a usable Increment toward a meaningful goal every Sprint, and using what they learn to change the plan. This page explains each element, walks through a realistic two-week Sprint, and lists the anti-patterns that most often hollow Scrum out.
TL;DR
- Scrum rests on empiricism (transparency, inspection, adaptation) and lean thinking, with the values commitment, focus, openness, respect, and courage.
- Three accountabilities: Product Owner (value and backlog), Scrum Master (effectiveness of Scrum), Developers (the Increment) — typically 10 or fewer people.
- Events: the Sprint (one month or less) containing Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
- Artifacts and commitments: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done.
- Every Sprint must produce at least one usable Increment that meets the Definition of Done.
- Watch for anti-patterns: no Sprint Goal, "Done" that is not done, status-meeting Daily Scrums, and retrospectives without change.
Quick Example
A two-week Sprint for a team building an invoicing product:
Core Concepts
Empiricism and Values
Scrum assumes that complex work cannot be fully planned up front, so it creates frequent opportunities to inspect results and adapt plans, based on transparent information. The values — commitment, focus, openness, respect, and courage — describe the behavior that makes this possible: being honest about problems, focusing on the Sprint Goal, and respecting each other's expertise.
Accountabilities
The Scrum Team is cross-functional and self-managing: it has the skills to deliver and decides how to do the work.
Events and Timeboxes
Product Backlog refinement — breaking down, clarifying, and estimating items — is an ongoing activity, not a formal event. The Product Owner may cancel a Sprint if the Sprint Goal becomes obsolete.
Artifacts and Commitments
The Sprint Goal gives the team focus and flexibility: if an item turns out larger than expected, the team negotiates scope with the Product Owner while still achieving the goal. Write backlog items with clear acceptance criteria; see Acceptance Criteria and Traceability.
Estimation and Forecasting
The Scrum Guide does not require story points or velocity. Many teams use relative estimates to forecast what fits in a Sprint; others use item counts and historical throughput. Either way, estimates are for the team's planning — not for comparing teams or measuring productivity. See Scrum vs Kanban.
Scrum at Scale
Multiple teams working on one product share one Product Backlog and Product Owner, integrate into one Increment every Sprint, and coordinate dependencies — the approach of frameworks such as Nexus, LeSS, and Scrum@Scale. Scaling works only when each team can deliver independently enough; otherwise coordination overhead dominates. See Engineering Management.
Best Practices
Always Have a Sprint Goal
Plan around one meaningful outcome, not a list of unrelated tickets.
Make "Done" Mean Usable
A strong Definition of Done — tested, integrated, deployed or deployable — keeps undone work from piling up.
Keep the Daily Scrum About the Goal
Discuss progress toward the Sprint Goal and impediments, not individual status reports to a manager.
Change Something Every Retrospective
Pick one or two improvements, assign owners, and add them to the next Sprint Backlog.
Common Mistakes
Sprints as Mini-Waterfalls
Proxy or Committee Product Owners
Retrospectives Without Action
FAQ
What is Scrum?
A framework for developing complex products in fixed-length Sprints, with defined accountabilities (Product Owner, Scrum Master, Developers), events, and artifacts that support frequent inspection and adaptation.
How long should a Sprint be?
One month or less; two weeks is the most common choice. Shorter Sprints provide faster feedback and smaller planning horizons.
Is the Scrum Master a project manager?
No. The Scrum Master is accountable for the team's effectiveness and for helping the organization use Scrum well — coaching, facilitating, and removing impediments — rather than assigning tasks or tracking individuals.
Does Scrum require story points?
No. The Scrum Guide does not mention story points or velocity. Teams may use any forecasting approach, including counting items and using historical throughput.
What is the Definition of Done?
A formal description of the quality an Increment must meet — for example code reviewed, tested, integrated, and deployable — shared by everyone so "Done" means the same thing.
Related Topics
- Agile Software Development — Values, principles, and frameworks
- Scrum vs Kanban — Choosing between iterations and flow
- Kanban — Managing work as continuous flow
- Product Prioritization — Ordering the Product Backlog
- Engineering Management — Supporting teams and scaling delivery
- Acceptance Criteria and Traceability — Clear, testable backlog items