What are the three Scrum artifacts, and which commitment does each one carry?

## Why Scrum names artifacts at all An **artifact** in Scrum is something the team maintains that represents work or value. Its job is to make a decision possible: someone reads it and knows what could be done next, what has been done, and whether the direction still holds. It is not a status report produced for an audience outside the team. Scrum names exactly three artifacts, and the count is deliberate — a team that treats its roadmap, its risk log or a progress chart as a fourth official artifact has quietly turned a helpful aid into an obligation. ## The three artifacts - **Product Backlog** — the single ordered list of everything that might be needed in the product. It is the only source of work the Scrum Team takes on, it is never complete, and it changes as the product and its users are better understood. - **Sprint Backlog** — the Sprint Goal, the items the Developers selected for the current Sprint, and their plan for delivering them. It is made by the Developers, for the Developers, and it is updated throughout the Sprint as more is learned. - **Increment** — a concrete, usable stepping stone toward the Product Goal. Each Increment is additive to every Increment before it and works alongside them; the sum of the Increments is the product as it stands today. ## Every artifact carries one commitment A **commitment** is a single statement bound to an artifact that says what that artifact is for. It is not a delivery promise, not a date, and not a scope agreement signed with a stakeholder. It is the yardstick a reader uses to judge whether the artifact is still coherent: an item that serves no commitment is a candidate for removal, and an artifact whose commitment nobody on the team can state out loud has degenerated into a list. | Artifact | What it holds | Its commitment | Question the commitment answers | | --- | --- | --- | --- | | Product Backlog | Ordered possibilities for the product | **Product Goal** | What is this product trying to become? | | Sprint Backlog | Selected items and the Developers' plan | **Sprint Goal** | Why is this Sprint worth running? | | Increment | Work meeting the agreed quality bar | **Definition of Done** | Is this work genuinely finished? | ### Product Backlog and the Product Goal The **Product Goal** is the longer-term objective the Product Backlog is working toward, and it lives inside that backlog rather than beside it: the list holds the things that might get the product there. A team pursues one Product Goal at a time and fulfils or abandons it before taking up the next. Its most practical value is that it gives a reason to decline work — an item nobody can connect to the current Product Goal has to argue for itself. ### Sprint Backlog and the Sprint Goal The **Sprint Goal** is the single objective of the Sprint. It is not the list of selected items and it is not a summary of that list; it states why the Sprint is worth running, and it should be phrased so that it could still be met even if the plan beneath it changed completely. That distinction is the entire point of separating goal from plan: the goal holds *why* steady while the Developers stay free to change *how*. ### Increment and its quality bar The **Increment** is usable work, and its commitment is the **Definition of Done** — the shared standard an item must meet before anyone may call it complete. Without a shared standard, "finished" means whatever the person saying it happens to mean, and the Increment stops being a trustworthy statement about the product. ## What the commitments buy a team 1. **Direction without a plan document.** The Product Goal carries intent that would otherwise live in a long-range plan nobody re-reads, and it is small enough to be recalled in a corridor. 2. **A basis for saying no.** Both goals turn "should we do this?" from a matter of who asked into a matter of whether the work serves the stated objective. 3. **One meaning of finished.** A single quality standard removes the most expensive ambiguity a team can carry: work that is counted as complete and is not. ## Confusions worth pre-empting - **Commitment does not mean promise.** The team commits to a purpose, not to a fixed scope on a fixed date. An interviewer listening for this distinction hears it immediately. - **The Sprint Goal is not the item list.** If removing one selected item would make the goal unreachable, the goal has probably been written as a list in disguise. - **Artifacts are for the team first.** They are readable by anyone, which is a consequence of keeping them honest, not their reason for existing. - **The Increment is not the demonstration.** It is the work itself; showing it to people is a separate activity that some teams do and none of them are required to do in order for the Increment to exist.