Scrum Basics

Scrum is a defined framework, not a catch-all label

The 2020 Scrum Guide defines Scrum as a lightweight framework through which people, teams, and organizations can generate value through adaptive solutions for complex problems. That wording matters because it limits the claim. Scrum is a framework: it supplies a deliberately small structure for work and learning rather than a complete method for every decision an organization faces. It is directed at complex problems, where important conditions can change and a team may learn as it works. It is oriented toward value, but it does not promise a particular financial result, product outcome, delivery date, or certification result.

In the Guide’s basic cycle, a Product Owner orders work for a complex problem in a Product Backlog. The Scrum Team turns selected work into a usable Increment during a Sprint. The team and relevant stakeholders inspect the result and adapt what happens next; then the cycle continues. The Guide describes Scrum as purposefully incomplete. It can contain other techniques and practices, but those additions should not be silently relabeled as Scrum itself. A board, a burndown chart, user-story wording, a particular software tool, or a prescribed set of daily questions may be useful in a context, yet none is required by the Scrum Guide’s definition.

Agile is a broader family of values, principles, approaches, and frameworks concerned with adaptive and iterative ways of working. Scrum is one framework often discussed in that context; Kanban is another distinct approach. The difference prevents a category error. Saying that a team uses an Agile approach does not establish that it follows Scrum. Conversely, a team may use the Scrum framework and supplement it with practices that the framework does not itself define. This lesson attributes formal Scrum terms to the Scrum Guide and leaves detailed Agile philosophy, Kanban flow practices, and organization-specific implementation for their own topics.

Empiricism makes learning part of the work

The Scrum Guide says Scrum is founded on empiricism and lean thinking. In this setting, empiricism means that knowledge comes from experience and decisions are based on what has been observed. Scrum uses an iterative, incremental approach: work proceeds through repeated Sprints, and usable additions to a product can create evidence about the result. The framework does not say that every uncertainty can be predicted away. Instead, it makes the current state of work and product visible enough for people to inspect and adapt.

The three empirical pillars are transparency, inspection, and adaptation. Transparency means that important aspects of the work and process are visible to the people doing the work and the people receiving it. Inspection means examining artifacts and progress toward agreed goals often enough to notice an undesirable difference or problem. Adaptation means adjusting the process or product when inspection shows that an acceptable limit has been exceeded or the result is unacceptable. The sequence is important: inspection without transparent information can mislead, and inspection with no resulting adjustment leaves the learning unused.

A Sprint is the containing event for this rhythm. It has a fixed length of one month or less, and a new Sprint begins immediately after the prior one ends. Sprint Planning, Daily Scrums, a Sprint Review, and a Sprint Retrospective occur within it. A shorter Sprint is not automatically better, and a fixed cadence does not make a forecast certain. Its educational value here is that regular boundaries create recurring opportunities to compare an intended goal, visible work, and an observed result. Scrum uses five events altogether: the Sprint plus the four events within it.

Two events are especially easy to confuse. The Sprint Review examines the Sprint’s outcome with key stakeholders and considers what to do next in light of what was accomplished and what changed in the environment. It is a working session, not merely a demonstration or approval ritual. The Sprint Retrospective is for the Scrum Team to examine how the Sprint went and to plan ways to improve quality and effectiveness. A Review therefore focuses on the product outcome and possible adaptation with stakeholders; a Retrospective focuses on the team’s ways of working. Neither event guarantees that stakeholders agree or that the next plan will be correct.

Accountabilities organize responsibility without assigning job titles

The basic unit in the framework is the Scrum Team: one Scrum Master, one Product Owner, and Developers. These are accountabilities, not a universal organizational chart or a set of employment titles. The Guide describes the team as a cohesive unit focused on one Product Goal at a time. It says the team is cross-functional, meaning it has the skills needed to create value in a Sprint, and self-managing, meaning it internally decides who does what, when, and how. Those descriptions explain the framework’s division of responsibility; they do not advise a particular employer how to hire, pay, evaluate, or reorganize people.

Developers are the people committed to creating any aspect of a usable Increment each Sprint. Their accountabilities include creating the Sprint Backlog plan, adhering to the Definition of Done, adapting the plan each day toward the Sprint Goal, and holding one another accountable as professionals. The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work and for effective Product Backlog management. That includes developing and communicating the Product Goal, creating and communicating backlog items, ordering them, and ensuring the Product Backlog is transparent, visible, and understood. The Product Owner is one person in the framework, even though that person may represent many stakeholder needs.

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness by enabling improvements within the framework. The Guide describes this accountability as service and leadership: for example, helping people understand Scrum, supporting self-management and cross-functionality, helping remove impediments, and helping ensure the formal events occur and stay within their timeboxes. This is not the same as being the team’s manager, assigning every task, or personally owning all outcomes. A careful reading separates framework accountability from an organization’s separate authority structures.

Artifacts and commitments create a shared basis for inspection

Scrum names three artifacts: the Product Backlog, Sprint Backlog, and Increment. Artifacts represent work or value and are intended to maximize transparency of key information. Each has a related commitment that provides focus and a basis for measuring progress. The Product Backlog is an emergent, ordered list of what is needed to improve the product; its commitment is the Product Goal, a future state that gives the team a longer-term target. The Product Backlog is not a fixed promise that every listed item will be delivered. It can be refined as more is learned.

The Sprint Backlog consists of the Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering an Increment. It is a plan by and for the Developers, and it can be updated as the team learns during the Sprint. Its commitment, the Sprint Goal, states the single objective for that Sprint. The goal provides coherence while allowing flexibility in the exact work needed to meet it; it is not a guarantee that all initially imagined tasks will remain unchanged.

An Increment is a concrete addition toward the Product Goal. It is additive to earlier Increments and must be usable to provide value. Its commitment is the Definition of Done: a formal description of the state of an Increment when it meets the product’s required quality measures. The Definition of Done creates a shared understanding of completed work. A backlog item that does not meet it is not part of an Increment. This does not mean that a Definition of Done replaces safety law, contractual obligations, independent testing, customer acceptance, or other obligations that may apply in a real setting. It is a framework commitment, not a universal compliance certificate.