From primitives to system
The Scrum Guide defines Scrum accurately in the sense that it does not contain false claims. The imprecision lies elsewhere: terms are introduced without establishing which ones are primitive and which are derived, concepts that have a strict sequential dependency are presented as parallel, and the boundary between what belongs to Scrum and what does not is left blurry. The result is a framework that is internally consistent but not systematically deconstructable — you cannot build it from the ground up because the ground is never shown.
This document reconstructs Scrum by doing the opposite. It identifies the smallest set of undefined terms (primitives) on which everything else rests, derives all other terms from those, and draws an explicit border around each one. The vocabulary section (Part II) is the formal record of this reconstruction. This section explains the relationships: why the terms are ordered the way they are, and what the structure of the system actually is.
Every concept in Scrum traces back to a single epistemic commitment: Empiricism. Empiricism holds that knowledge is only valid when grounded in observation — not in plans, models, or assumptions about how a complex system will behave. This is not a soft preference; it is a hard constraint. In a complex environment, the future state of a system cannot be predicted from its current state with sufficient accuracy for plans to be treated as facts.
Lean Thinking is the operational complement to Empiricism: if knowledge comes only from observation, then anything produced before it can be observed is waste until proven otherwise. Lean Thinking does not say "do less"; it says "don't produce more than can be inspected and validated." Together, Empiricism and Lean Thinking define the epistemic ground of Scrum. Neither is derived from Scrum itself — they are brought in from outside as axioms.
Everything else in Scrum is an answer to the question: what structures are minimally necessary to operate empirically?
The Scrum Guide presents Transparency, Inspection, and Adaptation as three parallel "pillars." This framing understates their relationship. They are not parallel — they are a strict sequential dependency:
Formally, this is a functional pipeline where each stage gates the next:
State(Transparency) → Execute(Inspection) → Δ > Limit → Execute(Adaptation)
If the input state lacks Transparency, Execute(Inspection) returns null — the pipeline stalls, and what follows is not inspection but guessing. If Execute(Inspection) does not produce a deviation check against the limit, Execute(Adaptation) has no trigger and becomes arbitrary change. The practical consequence is that Scrum's structures must guarantee all three in order. An artifact that is not transparent cannot be inspected. An event that does not produce an inspection result cannot trigger adaptation. This is the design logic behind every element of Scrum.
The three Scrum Artifacts — Product Backlog, Sprint Backlog, and Increment — exist specifically to create Transparency over distinct information domains. Each answers a different question:
Each artifact is paired with a Commitment — a publicly declared, inspectable Goal that anchors the artifact to something concrete. Without the Commitment, an artifact creates the appearance of Transparency without the substance: you can see the list, but you cannot inspect it against anything. The Commitment is what makes the artifact a target for Inspection.
The three Commitments are: Product Goal (for the Product Backlog), Sprint Goal (for the Sprint Backlog), and Definition of Done (for the Increment). Note that the Definition of Done is structurally different from the other two: it does not describe a desired future state of the product — it describes the minimum quality threshold that converts work into an Increment at all. It is a gate, not a goal.
Work in Scrum does not flow freely from intention to Increment. It passes through two gates, each structurally identical: a set of conditions evaluated as a conjunction. Both gates are of the form:
Gate(x) = ⋀ c(x) for c ∈ Gate, where each c : X → {⊤, ⊥}
The full pipeline is therefore:
Entry → [DoR(x)=⊤] → selected into Sprint → work → [DoD(x)=⊤] → Increment
The naming of both concepts obscures this symmetry entirely. "Ready" and "Done" are colloquial words pointing at checklists rather than at the mechanism. The mechanism is the same in both cases: a set whose conjunction must evaluate to true before the item can transition to the next type in the system. Seeing both as instances of the same structure makes the pipeline legible as a whole.
The five Formal Events are not meetings. They are precisely scheduled opportunities for Inspection and Adaptation, each targeting a specific artifact and its Commitment. The distinction matters because meetings are defined by attendance and agenda; Formal Events are defined by what must be inspected and what adaptation must result.
The Sprint is the container for all other events. It is not itself an event in the sense of Inspection — it is a time-box: a fixed interval that guarantees at least one complete empirical cycle (Transparency → Inspection → Adaptation) before any plan can persist unchecked. Sprint length is therefore not arbitrary: it is the maximum interval acceptable before the system must self-correct.
The four inner events each map to specific inspection targets:
Refinement is not a Formal Event. It is a continuous activity of maintaining the Product Backlog — breaking down and detailing Product Backlog Entries so they reach the transparency level required for Sprint Planning. Because it is not an event, it has no fixed timebox, no required output, and no Commitment attached to it. Treating Refinement as an event misreads its role in the system.
The Scrum Team is not defined by what its members do but by who is accountable for what. Scrum defines three non-overlapping accountability domains:
The critical distinction in Scrum's role structure is between Responsibility (who does the work) and Accountability (who owns the outcome). A Developer is responsible for building; the whole Scrum Team is accountable for delivering value. The Product Owner can delegate work to others but cannot delegate accountability for the product's value. Conflating these two is one of the most common sources of dysfunction in Scrum adoption.
The Scrum Team as a whole is self-managing: it decides internally who does what, when, and how. No external authority assigns tasks to Developers. The Organisation provides the context and the Goal — the Scrum Team controls the path.
A Sprint is the smallest time-box within which a full empirical cycle can complete: a Transparency state is established (Sprint Backlog), Inspection occurs (Sprint Review of the Increment), and Adaptation follows (updated Product Backlog, Retrospective improvements). Every element of the Sprint — its fixed length, the prohibition on Sprint Goal changes, the scope negotiability with the Product Owner — exists to protect the integrity of this cycle.
Sprint Prediction tools such as Burn-Down Charts, Burn-Up Charts, and Cumulative Flow Diagrams are external to the formal Scrum system. They may be useful for visualizing progress, but they carry no Commitment, they are not events, and their outputs are not artifacts. Using them does not conflict with Scrum; treating them as part of Scrum does.
Scope is not the same as Sprint Goal. The Sprint Goal is fixed for the duration of the Sprint — it is the Commitment that gives the Sprint its meaning. The Scope (which Product Backlog Entries are in the Sprint Backlog) can be renegotiated with the Product Owner as new Results emerge, as long as the Sprint Goal is not threatened. Conflating Scope with Sprint Goal produces either rigid over-commitment or goalless drift.
The vocabulary is organized into layers. Each layer may only reference terms defined in the same or earlier layers. Blue terms are primitives — axiomatic, not defined within Scrum. Green terms are derived. Red marks explicit demarcations.
These terms are brought into Scrum from outside. Scrum does not define them; it assumes them. They are the bedrock on which everything else is built.
Note on the logical floor: a condition throughout this document means a function f: X → {⊤, ⊥}. The values ⊤ (true) and ⊥ (false) are not defined further — they are primitive. Any attempt to define them requires using them. This is not a gap; it is the unavoidable floor of any formal system. Decomposition stops here by necessity, not by oversight.
Value
Is: The quality of a Solution that makes it desirable to Stakeholders. Defined externally to Scrum by the Organisation and its context. Scrum creates conditions for delivering it; Scrum does not define what it is.
Is not: A feature, a deliverable, or a metric. Scrum does not measure Value directly.
Problem
Is: A gap between the current state and a desired state (Goal). The reason Scrum is applied. Complex Problems are those where the gap cannot be closed by a known, repeatable procedure.
Is not: An obstacle during a Sprint (that is an impediment). A Problem is the motivating condition for the entire work, not a local disruption.
Goal
Is: A declared intent or desired future state. The reference point that gives any comparison of current state its meaning. Without a Goal, no observation can be evaluated as deviation or progress — it is just data. Goals are imported into Scrum from outside; Scrum does not produce Goals, it pursues them.
Is not: A task, a deliverable, or a plan. A task describes work; a Goal describes a state. A plan describes a path; a Goal describes a destination.
Empiricism
Is: The epistemological principle that knowledge is valid only when derived from observation. In complex environments, Empiricism is the only sound basis for decision-making because future states cannot be reliably predicted.
Is not: Data collection, reporting, or metrics. Empiricism is an epistemological stance, not a practice.
Lean Thinking
Is: The operating principle of eliminating everything that does not contribute to Value. Lean Thinking pairs with Empiricism: produce only what can be inspected and validated, and discard what cannot.
Is not: Minimalism or speed. Lean Thinking does not say "do less"; it says "do not produce more than can be validated."
Organisation
Is: The external entity that adopts Scrum, defines the broader Goal, and provides the context within which the Scrum Team operates. The Organisation is responsible for the Scrum Team's enabling conditions.
Is not: Part of the Scrum Team. The Organisation is the environment within which Scrum operates.
Stakeholder
Is: Any person or group with an interest in the product's outcome who is external to the Scrum Team. Stakeholder input informs the Product Backlog through the Product Owner.
Is not: A decision-maker within Scrum. Stakeholders have no authority over the Sprint, the Sprint Goal, or the Scrum Team's internal decisions.
Trust
Is: The emergent social condition that arises in systems where the current state is consistently observable, deviations are detected and named, and corrections follow. Trust enables the risk-taking necessary for empirical work; without it, people withhold information to protect themselves, which destroys the observability the system depends on.
Is not: A Scrum value, a practice, or a behavior that can be mandated. Trust is an outcome of a correctly operating system, not a precondition that can be declared into existence.
Responsibility
Is: The obligation to perform specific work. Imported from organizational design; Scrum does not invent it. Responsibility may be shared, delegated, or distributed — multiple people can be responsible for the same outcome. In Scrum, Responsibility is assigned within the Scrum Team by the team itself.
Is not: Accountability. Responsibility is about who does the work; Accountability is about who owns the outcome regardless of who did the work.
Accountability
Is: The non-delegable ownership of an outcome. Imported from organizational design; Scrum assigns it to specific roles but does not define the concept itself. Unlike Responsibility, Accountability cannot be shared — there is exactly one accountable party per domain. Delegating the work does not transfer the Accountability.
Is not: Responsibility. A person can be accountable for an outcome they did not personally produce. A person can be responsible for work without being accountable for the outcome.
Acceptable Limit
Is: The defined threshold that marks the boundary between expected variation and deviation that demands a response. Below this threshold, the system can continue without intervention; above it, the system must correct. Without Acceptable Limits, any observation is structurally undecidable — there is no criterion to distinguish signal from noise.
Is not: A quality standard or a performance target. Acceptable Limits do not describe what "good" looks like; they describe the point at which "not good enough" triggers a mandatory response.
Defined using only Layer 0 primitives.
Transparency
Derived from Empiricism, Goal
Is: The epistemic state in which information necessary for making a decision is visible to those who need to make it. Transparency is a precondition for Inspection. It is not created by reporting — it is created by structuring work so its current state is observable without interpretation.
Is not: An action, a meeting, or a report. Transparency is a property of the system, not an activity within it.
Inspection
Derived from Transparency, Goal, Acceptable Limit
Is: The act of comparing an observable current state against a Goal to detect deviation. Inspection requires prior Transparency.
Is not: Surveillance, review of work quality, or approval. Inspection is a structured comparison, not a judgment of individuals or outputs.
Adaptation
Derived from Inspection, Acceptable Limit
Is: A deliberate change to process, plan, or product made in response to a deviation detected by Inspection that exceeds Acceptable Limits. Adaptation must follow Inspection as quickly as possible to prevent further deviation.
Is not: Arbitrary change, continuous improvement in the abstract, or reactive firefighting. Adaptation is always triggered by a specific Inspection result, not by preference or habit.
Continuity
Derived from Value, Empiricism
Is: The sustained capacity of the Scrum Team to deliver Increments over time without degradation of quality or pace. Scrum protects Continuity by limiting Sprint length and prohibiting changes that destabilize the team.
Is not: Velocity or throughput. Continuity is about sustainable capacity, not speed.
Defined using Layer 0 and Layer 1 terms.
Commitment
Derived from Goal, Transparency
Is: A publicly declared, inspectable Goal attached to a Scrum Artifact. A Commitment converts an artifact from a list or plan into an inspectable entity — it is the anchor for Inspection. There are exactly three Commitments in Scrum, one per artifact.
Is not: A promise, a contract, or a guarantee of delivery. A Commitment defines what is being inspected, not what will definitely happen.
Definition of Done (DoD)
Derived from Commitment, Value, Acceptable Limit
Is: A set of conditions — not a list (no inherent order; members are distinct) — whose conjunction defines the membership predicate for the type Increment:
DoD_predicate(x) = ⋀ c(x) for c ∈ DoD
Work passes the gate and becomes an Increment iff DoD_predicate(x) = ⊤. There is no partial satisfaction: ⊥ on any single condition returns ⊥ for the whole. Applied uniformly to all work in a Sprint. The DoD is the Commitment of the Increment artifact and the second gate in the two-gate pipeline (see Part I, "The Two-Gate Pipeline").
Is not: An acceptance criterion (which is item-specific and may vary), a description of "good" work, or a checklist that can be partially satisfied. The DoD does not describe quality aspirations — it defines the minimum threshold below which output has no formal status in Scrum.
Definition of Ready (DoR)
Derived from Acceptable Limit, Transparency
Is: A set of conditions — structurally identical to the Definition of Done — whose conjunction defines the gate a Product Backlog Entry must pass to be selectable in Sprint Planning:
DoR_predicate(x) = ⋀ c(x) for c ∈ DoR
An entry may enter Sprint Planning iff DoR_predicate(x) = ⊤. The DoR is team-defined and not formally specified in the Scrum Guide; it operationalizes the Transparency requirement for Sprint Planning. It is the first gate in the two-gate pipeline.
Is not: A formal Scrum Commitment. Unlike the DoD, the DoR has no artifact attached to it in the Scrum framework — it is a practical tool, not a structural element. It is the same type of thing as the DoD, operating at a different point in the pipeline. "Ready" names the checklist; it does not name the mechanism.
Result
Derived from Goal, Inspection
Is: The observable state produced by a Sprint or event, measured against a Goal. Result is what Inspection operates on.
Is not: Output. Output is produced work; Result is produced work in relation to a Goal. An Increment is a Result only if it meets the Definition of Done.
Solution
Derived from Problem, Value
Is: The product, service, or system that closes the gap defined by a Problem and delivers Value. Scrum does not define what a Solution must be — it provides the framework for discovering and building one empirically.
Is not: The Increment. An Increment is a step toward a Solution; it is not the Solution itself until the Product Goal is met.
Scrum Artifact
Derived from Transparency, Commitment
Is: A formal structure in Scrum that makes specific information transparent and carries a Commitment that anchors Inspection. There are exactly three: Product Backlog, Sprint Backlog, and Increment.
Is not: Any document, board, or tool a team uses. Only the three formally defined artifacts are Scrum Artifacts.
Increment
Derived from Definition of Done, Value
Is: A concrete, usable step toward the Product Goal. An Increment is additive to all prior Increments and must satisfy the Definition of Done to exist as an Increment at all. Multiple Increments may be produced per Sprint.
Is not: Completed tasks, delivered features, or any work that does not meet the Definition of Done. Work not meeting the DoD is not an Increment — it is incomplete work.
Product Backlog
Derived from Transparency, Commitment, Goal
Is: An emergent, ordered list of everything needed to improve the product, and the single source of work for the Scrum Team. Its Commitment is the Product Goal. "Emergent" means the list is never complete — it evolves as understanding grows.
Is not: A requirements document, a backlog of issues, or a task list. It is ordered by value and readiness, not by submission time or team preference.
Sprint Backlog
Derived from Transparency, Commitment, Goal
Is: The Sprint Goal (Commitment), the selected Product Backlog Entries, and the Developers' plan for delivering the Increment. A real-time, Developer-owned picture of the Sprint's work. Updated throughout the Sprint as more is learned.
Is not: A contract or a fixed plan. The Sprint Backlog is a plan for Developers, by Developers — it is not assigned by any external party.
Product Goal
Derived from Commitment, Goal, Value
Is: The long-term Goal of the Scrum Team for the product. The Commitment of the Product Backlog. The Scrum Team pursues one Product Goal at a time; it must be either fulfilled or abandoned before the next is adopted.
Is not: A roadmap, a vision statement, or a collection of goals. It is singular, inspectable, and time-bounded by Sprint cycles.
Sprint Goal
Derived from Commitment, Goal
Is: The single Goal for one Sprint. The Commitment of the Sprint Backlog. It gives the Sprint coherence and provides the anchor against which the Daily Scrum and Sprint Review inspect progress. The Sprint Goal is fixed for the Sprint's duration.
Is not: The Sprint Scope. Scope (which Product Backlog Entries are in the Sprint) may be renegotiated; the Sprint Goal may not. Replacing the Sprint Goal mid-Sprint constitutes canceling the Sprint.
Product Backlog Entry
Derived from Product Backlog
Is: A single element of the Product Backlog, describing work toward the Product Goal. Its attributes (description, order, size, detail) vary by context. Entries are refined until they reach the transparency level required for Sprint Planning.
Is not: A task. Tasks are what Developers break entries into during Sprint execution. An entry is a unit of product value; a task is a unit of implementation work.
Sprint
Derived from Inspection, Adaptation, Acceptable Limit
Is: A fixed-length time-box of one month or less that serves as the container for all other Formal Events. The Sprint is the minimal interval within which one complete empirical cycle (Transparency → Inspection → Adaptation) must complete. A new Sprint begins immediately when the previous one ends.
Is not: A project phase, a delivery milestone, or a work period. The Sprint's fixed length is not a deadline — it is the frequency of the empirical control loop. Sprints do not "end when the work is done"; they end when the time-box expires.
Formal Event
Derived from Inspection, Adaptation, Transparency
Is: A timeboxed, purpose-defined opportunity to inspect a specific Scrum Artifact and its Commitment, and to adapt accordingly. There are exactly five Formal Events in Scrum. Each has a maximum timebox and a defined output.
Is not: A meeting, a ceremony, or a team ritual. A Formal Event is defined by its inspection target and required adaptation outcome, not by attendance or agenda format.
Scrum Team
Derived from Scrum Artifact, Goal, Continuity
Is: A small, self-managing, cross-functional unit consisting of one Scrum Master, one Product Owner, and one or more Developers. Accountable for delivering a valuable Increment each Sprint. No sub-teams, no hierarchy within.
Is not: A department, a squad with a manager, or a project team with rotating roles. The Scrum Team is a stable accountability unit.
Developer
Derived from Responsibility, Increment, Definition of Done
Is: The accountability within the Scrum Team for every aspect of a usable Increment each Sprint. Developers create the Sprint Backlog, uphold the Definition of Done, adapt their plan daily toward the Sprint Goal, and hold each other accountable.
Is not: A job title or a software engineer role. "Developer" in Scrum is the name for the execution accountability within the Scrum Team. Anyone contributing to the Increment in a Sprint is operating as a Developer.
Product Owner
Derived from Accountability, Product Backlog, Product Goal, Value
Is: One person accountable for maximizing the value of the product and for effective Product Backlog Management: developing the Product Goal, creating and ordering Product Backlog Entries, and ensuring the Product Backlog is transparent and understood.
Is not: A committee, a proxy, or a business analyst. The Product Owner is a single person with singular accountability. Delegating tasks is acceptable; delegating accountability is not.
Scrum Master
Derived from Accountability, Empiricism, Organisation
Is: The accountability within and around the Scrum Team for Scrum being understood and enacted as defined. The Scrum Master serves the Scrum Team (coaching self-management, removing impediments), the Product Owner (effective Product Backlog Management), and the Organisation (Scrum adoption, empirical thinking for complex work).
Is not: A project manager, a team lead, a facilitator of all meetings, or a coordinator. The Scrum Master's accountability is for the framework's effectiveness, not for the work's outcomes or the team's schedule.
Sprint Planning
Derived from Formal Event, Sprint, Sprint Backlog
Is: The Formal Event that initiates the Sprint. The whole Scrum Team collaborates to establish the Sprint Goal, select Product Backlog Entries, and create the Developers' plan for delivering the Increment. Output: Sprint Backlog. Timebox: 8 hours for a one-month Sprint.
Is not: A requirements discussion, a task assignment session, or a review of past work. Its sole purpose is to produce a Sprint Backlog with a coherent Sprint Goal.
Daily Scrum
Derived from Formal Event, Sprint Goal, Sprint Backlog
Is: A 15-minute Formal Event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog for the next 24 hours. Structure and format are chosen by the Developers. Timebox: 15 minutes, daily at the same time and place.
Is not: A status report, a standup for the Scrum Master, or a planning session. Its inspection target is the Sprint Goal; its adaptation output is the plan for the next day.
Sprint Review
Derived from Formal Event, Increment, Product Goal, Stakeholder
Is: The Formal Event where the Scrum Team and key Stakeholders inspect the Increment and progress toward the Product Goal, then adapt the Product Backlog accordingly. A working session, not a presentation. Timebox: 4 hours for a one-month Sprint.
Is not: A demo, a sign-off meeting, or a delivery gate. The Sprint Review is an inspection of the Increment in relation to the Product Goal; acceptance of individual items is not its purpose.
Sprint Retrospective
Derived from Formal Event, Scrum Team, Definition of Done
Is: The final Formal Event of a Sprint. The Scrum Team inspects its own process, interactions, tools, and Definition of Done from the past Sprint, identifies the most useful improvements, and adapts accordingly. Improvements may be added to the Sprint Backlog. Timebox: 3 hours for a one-month Sprint.
Is not: A complaint session, a retrospective on the product, or optional. The Sprint Retrospective is the mechanism by which the Scrum Team improves its own effectiveness — skipping it removes the system's capacity for self-correction.
Refinement
Derived from Product Backlog, Transparency
Is: A continuous activity (not a Formal Event) of breaking down and detailing Product Backlog Entries until they are small enough and transparent enough to be selected in Sprint Planning. No fixed timebox; no Commitment; no required output format.
Is not: A Formal Event, a meeting with a fixed agenda, or a handover of requirements. Refinement happens as needed, governed by the Product Backlog's state and the upcoming Sprint Planning.
Product Backlog Management
Derived from Product Backlog, Product Goal, Value
Is: The ongoing accountability of the Product Owner for maintaining the Product Backlog: developing and communicating the Product Goal, creating and ordering Product Backlog Entries, and ensuring the list is transparent. Includes but is not limited to Refinement.
Is not: Project management, sprint management, or a shared team responsibility. Product Backlog Management accountability is singular and non-delegable.
Scope
Derived from Sprint Backlog, Sprint Goal
Is: The set of Product Backlog Entries selected into the Sprint Backlog during Sprint Planning. Scope may be renegotiated with the Product Owner during the Sprint as understanding grows, provided the Sprint Goal is not threatened.
Is not: The Sprint Goal. These are distinct: the Sprint Goal is fixed, the Scope is flexible within the constraint of the Sprint Goal.
Task
Derived from Developer, Product Backlog Entry
Is: A unit of implementation work that Developers decompose Product Backlog Entries into during Sprint execution. Typically one day or less. Managed entirely by the Developers; not a formal Scrum structure.
Is not: A Product Backlog Entry. Tasks are execution-level; entries are product-level. Tasks exist within the Sprint Backlog, not the Product Backlog.
Sprint Prediction
Derived from Empiricism, Sprint
Is: A probabilistic estimate of what can be completed within a Sprint, based on observed past performance. Useful for planning and communication.
Is not: A Commitment, an artifact, or a Formal Event output. Sprint Prediction has no formal status in Scrum and must not substitute for the empirical cycle.
Burn-Down Chart / Burn-Up Chart / Cumulative Flow Diagram
Derived from Sprint Prediction, Sprint Backlog
Is: Visualization tools for tracking work progress within a Sprint or across Sprints. Useful for making the state of the Sprint Backlog visible.
Is not: A formal Scrum Artifact, a Commitment, or a control mechanism. These tools support Transparency but carry no formal weight in the Scrum system.
Scrum Values
Is: The five values whose consistent enactment enables the empirical pillars to function: Commitment (to goals, not to plans), Focus (on the Sprint work), Openness (toward the work and challenges), Respect (for each other as capable people), Courage (to do the right thing on hard problems). These are not behavioral rules — they are the social conditions under which Transparency, Inspection, and Adaptation become possible.
Is not: A code of conduct, a set of personality requirements, or measurable KPIs.
Scrum Theory
Is: The theoretical foundation of Scrum, consisting of Empiricism and Lean Thinking, operationalized through the three Scrum Pillars (Transparency, Inspection, Adaptation) and sustained by the Scrum Values. Scrum Theory is the "why" behind every structural choice in Scrum.
Is not: The Scrum rules. The rules (roles, events, artifacts) are the "what." Scrum Theory is the "why" that justifies the "what" and guides decisions in situations the rules do not cover.
Scrum Philosophy
Is: The broader orientation from which Scrum Theory follows: that complex problems cannot be solved through upfront planning, and that value delivery requires iterative, observable, adaptive work. Scrum Philosophy is not argued for within Scrum — it is presupposed by it.
Is not: Agile as a whole. Scrum Philosophy is the specific epistemological stance of Scrum; Agile is a broader umbrella under which multiple frameworks operate.
Every English term used in this document, mapped to its German equivalent as used in the 2020 Scrum Guide (German edition) and standard German Scrum practice. Terms identical in both languages are omitted.
| English | German |
|---|---|
| Value | Wert |
| Goal | Ziel |
| Empiricism | Empirie |
| Trust | Vertrauen |
| Acceptable Limit | akzeptable Grenze |
| Responsibility | Umsetzungsverantwortung |
| Accountability | Ergebnisverantwortung |
| Transparency | Transparenz |
| Inspection | Überprüfung |
| Adaptation | Anpassung |
| Continuity | Kontinuität |
| Result / Outcome | Ergebnis |
| Solution | Lösung |
| Scrum Artifact | Scrum-Artefakt |
| Product Goal | Produkt-Ziel |
| Sprint Goal | Sprint-Ziel |
| Product Backlog Entry | Product-Backlog-Eintrag |
| Product Backlog Entries | Product-Backlog-Einträge |
| Product Backlog Management | Product-Backlog-Management |
| Formal Event | formales Event |
| Task | Aufgabe |
| Sprint Prediction | Sprint-Vorhersage |
| Cumulative Flow Diagram | Cumulative-Flow-Diagramm |
| Scrum Theory | Scrum-Theorie |
| Scrum Values | Scrum-Werte |
| Scrum Philosophy | Scrum-Philosophie |
| Scrum Pillar | Scrum-Säule |
| Scrum Practice | Scrum-Praxis |
| Focus | Fokus |
| Openness | Offenheit |
| Respect | Respekt |
| Courage | Mut |
Schwaber, K. & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. scrumguides.org