TL;DR
Scrum is a lightweight framework for addressing complex problems through short, repeated cycles. A Product Owner orders product needs, a cross-functional Scrum Team creates a usable Increment during a Sprint, and the team and stakeholders inspect the result before adapting what happens next. Scrum defines a small set of accountabilities, events, artifacts, commitments, and rules. It leaves engineering and product-management techniques to the people using it.
Scrum gives a team a regular way to turn an idea into something usable, inspect the result, and adjust its direction. It is widely associated with Agile software development, although it can be applied to other kinds of complex work.
The current official definition comes from the November 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland.
What is Scrum?
Scrum is a framework, meaning it supplies a minimal structure within which people choose appropriate practices. It does not prescribe how to write requirements, design architecture, estimate work, test software, or deploy a release.
The framework coordinates four recurring actions:
- A Product Owner orders possible work in a Product Backlog.
- The Scrum Team selects a valuable objective and related work for a Sprint.
- The team creates at least one usable product Increment.
- The Scrum Team and stakeholders inspect the outcome and adapt future work.
Then another Sprint begins.
Scrum is intentionally incomplete. The team must add the product, engineering, security, and operational practices required for its field and situation.
Why Scrum is used for complex work
A complex problem contains important unknowns. The relationship between an action and its result may only become clear after the team tries something and observes what happens.
For example, a clinic may know that patients struggle to book appointments, but it may not know:
- which part of the booking journey causes the most abandonment
- whether patients prefer search by doctor, date, or location
- how the new service will change reception workload
- which reminder method will reduce missed appointments
Detailed planning cannot answer every question. Scrum creates a regular cadence, or rhythm, for producing evidence and using it in the next decision.
Scrum theory: empiricism and Lean thinking
Scrum is founded on empiricism and Lean thinking.
Empiricism means that knowledge comes from experience and that decisions use what can be observed. A plan remains useful, but real results can change it.
Lean thinking focuses attention on value and essentials while reducing waste. In Scrum, short feedback cycles and visible work help the team find effort that is not moving the product toward its goal.
Empiricism operates through three pillars:
| Pillar | Meaning | Practical question |
|---|---|---|
| Transparency | Important work, quality standards, goals, and results are visible and understood. | Do people share an accurate view of the product and work? |
| Inspection | The team and stakeholders examine progress and outcomes frequently enough to detect problems. | What does the current evidence show? |
| Adaptation | Plans, work, or practices change when inspection reveals a meaningful difference. | What should change because of what we learned? |
Inspection without transparency relies on incomplete information. Inspection without adaptation becomes observation without action.
The five Scrum values
Scrum identifies five values that guide behaviour:
| Value | What it means in practice |
|---|---|
| Commitment | Team members support one another and work toward agreed goals. |
| Focus | Attention stays on the Sprint Goal and the work needed to make meaningful progress. |
| Openness | The team and stakeholders are honest about work, risk, uncertainty, and problems. |
| Respect | People treat one another as capable professionals and listen to relevant expertise. |
| Courage | People raise difficult issues, make necessary changes, and work on hard problems. |
Events and artifacts cannot create trust by themselves. The values shape how people use Scrum’s structure when plans fail, opinions differ, or an uncomfortable risk becomes visible.
The Scrum Team
The fundamental unit of Scrum is one small Scrum Team. It consists of:
- one Product Owner
- one Scrum Master
- Developers
These are accountabilities, not necessarily job titles. An accountability states who is answerable for a result. One person may have a separate organizational title such as designer, engineer, analyst, or tester while serving as a Developer in Scrum.
The Scrum Guide describes the team as:
- cross-functional, with the skills needed to create value each Sprint
- self-managing, deciding internally who does what, when, and how
- focused on one Product Goal at a time
- typically ten or fewer people
- free of sub-teams and internal hierarchies
“Developer” has a broad meaning in Scrum. It includes the people creating any part of the usable Increment, not only people who write code.
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work.
The Product Owner is also accountable for effective Product Backlog management:
- developing and communicating the Product Goal
- creating and communicating Product Backlog items
- ordering those items
- keeping the Product Backlog visible and understood
The Product Owner may ask others to help with this work, but the accountability stays with the Product Owner.
The Product Owner is one person, not a committee. That person represents many stakeholder needs and makes ordering decisions visible through the Product Backlog.
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness.
This includes:
- helping people understand Scrum theory and practice
- coaching the team in self-management and cross-functionality
- helping the team focus on valuable Increments that meet the Definition of Done
- causing impediments to be removed
- helping Scrum events remain useful and within their timeboxes
- helping the Product Owner with Product Goal and Product Backlog practices
- helping the wider organization work effectively with Scrum Teams
An impediment is a condition that obstructs meaningful progress. The Scrum Master may help remove it, but does not need to solve every problem personally.
The Scrum Master is not a project manager who assigns tasks, collects status, or directs the Developers. Scrum depends on the team managing its own work.
Developers
Developers are the members committed to creating a usable Increment during each Sprint.
They are accountable for:
- creating the Sprint Backlog
- building quality through the Definition of Done
- adapting their plan each day toward the Sprint Goal
- holding one another accountable as professionals
The Developers decide how to turn selected Product Backlog items into an Increment. The Product Owner is accountable for product value and backlog ordering; the Developers control their delivery plan.
The five Scrum events
Scrum defines five events. The Sprint contains the other four.
| Event | Purpose | Maximum timebox |
|---|---|---|
| Sprint | Create consistency and a regular opportunity to produce value and learn. | One month or less |
| Sprint Planning | Agree why the Sprint is valuable, what may be completed, and how the work will be approached. | Eight hours for a one-month Sprint |
| Daily Scrum | Inspect progress toward the Sprint Goal and adapt the upcoming plan. | 15 minutes each working day |
| Sprint Review | Inspect the Sprint outcome with stakeholders and determine useful future adaptations. | Four hours for a one-month Sprint |
| Sprint Retrospective | Plan improvements to quality and team effectiveness. | Three hours for a one-month Sprint |
Events are usually shorter for shorter Sprints. A timebox is a maximum duration, not a target that every event must consume.
flowchart LR PB["Product Backlog<br/>ordered toward Product Goal"] --> SP["Sprint Planning"] SP --> SB["Sprint Backlog<br/>Sprint Goal + selected items + plan"] subgraph S["Sprint: one month or less"] SB --> W["Create and verify the Increment"] W --> DS["Daily Scrum<br/>inspect and adapt the plan"] DS --> W W --> I["Usable Increment"] I --> SR["Sprint Review"] SR --> RETRO["Sprint Retrospective"] end SR -. "product feedback" .-> PB RETRO -. "process improvement" .-> SP
The Sprint
Sprints are fixed-length cycles of one month or less. A new Sprint begins immediately after the previous one.
During a Sprint:
- the Sprint Goal is protected
- quality does not decrease
- the Product Backlog is refined as needed
- scope can be clarified and renegotiated with the Product Owner as the team learns
Fixed length limits the amount of time and cost exposed before inspection. Shorter Sprints create more frequent learning opportunities, but they also increase the frequency of planning, review, and retrospective events.
Only the Product Owner can cancel a Sprint, and only when its Sprint Goal becomes obsolete. A difficult Sprint is not automatically a reason to cancel it.
Sprint Planning
Sprint Planning starts the Sprint through the collaborative work of the entire Scrum Team. It addresses three questions:
- Why is this Sprint valuable? The Scrum Team establishes a Sprint Goal.
- What can be completed? Developers select Product Backlog items after discussing value, capacity, quality, and past performance.
- How will the work get done? Developers create an actionable plan for producing an Increment that meets the Definition of Done.
Together, the Sprint Goal, selected Product Backlog items, and delivery plan form the Sprint Backlog.
The selected work is a forecast, meaning the Developers’ best current expectation. The Sprint Goal provides the commitment and direction while the exact plan can adapt.
Daily Scrum
The Daily Scrum is a 15-minute event for the Developers. Its purpose is to inspect progress toward the Sprint Goal and adjust the Sprint Backlog.
Developers choose the format. Scrum does not require each person to answer three status questions. The event should produce an actionable plan for the next working day.
If the Product Owner or Scrum Master is working on Sprint Backlog items, they participate in the Daily Scrum as Developers. The event is not a report to either role.
Detailed problem-solving can happen immediately after the Daily Scrum among the relevant people. Developers can also re-plan together at any other time.
Sprint Review
The Scrum Team and key stakeholders inspect the Sprint outcome, discuss progress toward the Product Goal, consider changes in the environment, and decide what may be valuable next.
The Sprint Review is a working session, not a presentation performed only to receive approval. Stakeholder feedback may change the Product Backlog.
The Sprint Review is also not a release gate. A usable Increment may be delivered before the Sprint ends if that timing creates value and satisfies the necessary release controls.
Sprint Retrospective
The Scrum Team inspects how the Sprint went across people, interactions, processes, tools, and quality. It then identifies changes that could increase quality and effectiveness.
The most helpful improvement may be added to the next Sprint Backlog or addressed sooner. A retrospective has value when it changes behaviour or removes a recurring obstacle.
The Sprint Retrospective concludes the Sprint.
The three Scrum artifacts and their commitments
An artifact makes important work or value visible. Each Scrum artifact has a related commitment that supplies focus and a basis for measuring progress.
| Artifact | What it contains or represents | Commitment |
|---|---|---|
| Product Backlog | the evolving, ordered work needed to improve the product | Product Goal |
| Sprint Backlog | the Sprint Goal, selected Product Backlog items, and delivery plan | Sprint Goal |
| Increment | the usable product result created from completed work | Definition of Done |
Product Backlog and Product Goal
The Product Backlog is the single source of work undertaken by the Scrum Team. It is emergent, meaning its content and detail develop as the team learns.
Product Backlog items are not required to be user stories. They can represent features, defects, experiments, security improvements, research, technical debt, or other product work.
Product Backlog refinement is the ongoing activity of breaking items down and adding useful details such as description, order, and size. It is an activity, not a formal Scrum event.
The Product Goal describes a future product state that gives the Scrum Team a longer-term objective. The rest of the Product Backlog emerges to define possible ways of reaching it.
Sprint Backlog and Sprint Goal
The Sprint Backlog is a plan by and for the Developers. It contains:
- why the Sprint matters, expressed by the Sprint Goal
- what the Developers selected from the Product Backlog
- how they currently plan to create the Increment
The Sprint Backlog changes throughout the Sprint as more is learned.
The Sprint Goal is the Sprint’s single objective. It allows flexibility in the exact work used to achieve that objective. If implementation differs from the original expectation, Developers and the Product Owner can renegotiate scope without endangering the goal.
Increment and Definition of Done
An Increment is a usable addition to the product that moves it toward the Product Goal. It must work together with previous Increments and be verified.
Several Increments may be created during one Sprint. Work becomes part of an Increment only when it meets the Definition of Done.
The Definition of Done is the shared quality description for a completed Increment. Depending on the product, it may require:
- reviewed and integrated code
- automated and manual tests
- security, privacy, and accessibility checks
- updated documentation
- operational monitoring
- successful deployment to a required environment
If a Product Backlog item does not meet the Definition of Done, it is not part of the Increment and cannot be presented as completed work.
Definition of Done and acceptance criteria
Acceptance criteria describe conditions for an individual Product Backlog item or requirement. The Definition of Done is the common quality standard applied to the Increment. A completed item normally needs to satisfy both.
How Scrum fits the SDLC
Scrum organizes product work but does not replace the Software Development Life Cycle.
| SDLC concern | How a Scrum Team may address it |
|---|---|
| Product direction | Product Goal and Product Backlog ordering |
| Requirements | Product Backlog items, conversations, acceptance criteria, and relevant specifications |
| Design and architecture | design work within and across Sprints, guided by product risk |
| Development and testing | cross-functional work needed to create a usable Increment |
| Security and compliance | requirements and checks included in product work and the Definition of Done |
| Release | delivery of usable Increments when release conditions are satisfied |
| Operations and maintenance | monitoring, incidents, defects, and maintenance represented as product work |
| Improvement | Sprint Reviews adapt the product; Sprint Retrospectives adapt how the team works |
Scrum does not require every discovery, architecture, release, or operational activity to start and finish neatly within one Sprint. The Scrum Team remains responsible for all product-related activities and manages them in a way that supports usable Increments and the Product Goal.
Example: a clinic booking product
Suppose a Scrum Team is improving online appointment booking.
Product Goal
Patients can find and manage suitable clinic appointments without calling reception.
The Product Backlog contains appointment search, booking, cancellation, reminders, accessibility improvements, audit records, performance work, defects, and research.
For one Sprint, the Scrum Team creates this Sprint Goal:
Allow a small group of patients to find and reserve an available appointment safely.
Developers select the relevant Product Backlog items and create a delivery plan. During the Sprint, they design the interaction, implement the booking rules, test concurrent reservations, add monitoring, and prepare the limited release.
The Definition of Done requires code review, automated tests, security checks, accessibility checks, operational alerts, and support documentation.
At the Sprint Review, patients, reception staff, and clinic representatives inspect the working result. They discover that patients want to search by location before selecting a doctor. The Product Owner uses that evidence when reordering the Product Backlog.
At the Sprint Retrospective, the Scrum Team identifies that slow access to test data delayed verification. It agrees on an improvement for the next Sprint.
Product learning and team improvement happen through different events, and both inform later work.
Common misunderstandings
- The Scrum Master manages the team: The Scrum Master establishes Scrum and supports effectiveness. Developers manage their own delivery plan.
- The Product Owner assigns tasks: The Product Owner orders product work. Developers decide how to deliver the Increment.
- The Product Backlog is a complete requirements document: It evolves as the product and evidence change.
- Every backlog item must be a user story: Scrum does not prescribe a format for Product Backlog items.
- A Sprint must last two weeks: Any fixed length of one month or less is valid.
- Sprint scope can never change: Scope may be clarified and renegotiated as long as the Sprint Goal is protected.
- The Daily Scrum is a status meeting: It is a planning and adaptation event for Developers.
- The Sprint Review is a demonstration or approval gate: It is a collaborative inspection of the outcome and future direction.
- The Increment must wait until the Sprint ends for release: A usable Increment may be delivered earlier.
- Unfinished work receives partial credit: Work that does not meet the Definition of Done is not part of the Increment.
- Scrum supplies engineering practices: Teams must still choose suitable design, testing, security, integration, deployment, and operational practices.
When Scrum is a reasonable fit
Scrum is useful when:
- the problem is complex and benefits from repeated inspection
- a small, cross-functional team can focus on one Product Goal
- a Product Owner can make product-ordering decisions
- stakeholders can inspect real outcomes regularly
- the team can create a usable Increment at least once per Sprint
- the organization allows the Scrum Team to manage its own work
Scrum struggles when the Product Owner lacks authority, the team is split across too many unrelated goals, dependencies prevent it from creating usable results, or events are treated as reporting ceremonies.
Adopting Scrum terminology without its goals, accountabilities, usable Increments, and empirical decisions creates the appearance of Scrum without its feedback system.
Summary
- Scrum is a lightweight framework for generating value while addressing complex problems.
- It uses empiricism, Lean thinking, and an iterative, incremental approach.
- The Scrum Team consists of a Product Owner, Scrum Master, and Developers.
- Scrum has five events: the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
- Its three artifacts are the Product Backlog, Sprint Backlog, and Increment.
- The related commitments are the Product Goal, Sprint Goal, and Definition of Done.
- Scrum does not prescribe user stories, estimation units, software-engineering methods, or a two-week Sprint.
- Scrum organizes work within the SDLC; it does not replace lifecycle responsibilities.
Related topics
- Software Development Life Cycle
- SDLC Development Approaches
- Agile Software Development
- SDLC Development Practices