Scrum Artifacts — Product Backlog, Sprint Backlog, and Increment

Scrum's three artifacts — the Product Backlog, the Sprint Backlog, and the Product Increment — all exist in service of one shared goal: maximize transparency. Each artifact pairs with a specific commitment that progress gets measured against, and PMI likes testing that pairing directly: the Product Backlog's progress is measured via the Product Goal, the Sprint Backlog's progress is measured via the Sprint Goal, and the Product Increment's progress is measured via the Definition of Done.

Product Backlog — a prioritized set of all the requirements the product might ever need, written in the form of user stories. The Product Owner owns it — and owns it alone; nobody else unilaterally reprioritizes it. It captures everything: features, functional requirements, non-functional requirements like security and performance, defect fixes, quality attributes, and compliance requirements. It's explicitly a living and emergent document, not a document that's "finished" and then executed against — new understanding, new feedback, and new priorities continuously reshape it over the life of the product.

Product Backlog attributes — four properties every well-formed backlog item should have: Item Description (what it actually is), Priority Order (where it sits relative to everything else), Estimate (how big it is), and Value (why it matters). The backlog is regularly refined — detailed, decomposed, prioritized, and validated — so that items near the top are clear and ready to pull into a sprint, while items further down can stay intentionally vague until they're closer to being worked.

Sprint Backlog — the prioritized subset of requirements selected from the Product Backlog for the current sprint. The Product Owner still owns the Product Backlog, but detailed and refined user stories become part of the Sprint Backlog as the team adds its own task-level detail underneath each story. The team inspects its progress against the Sprint Backlog every day in the Daily Scrum, and Definition of Done and acceptance criteria get added to any story that's missing them before work starts.

The Sprint Backlog is made up of three things: the Sprint Goal (the single objective the sprint exists to achieve), the User Stories selected for the sprint, and the Tasks underneath each story — together forming an actionable plan for actually delivering the increment, not just a restated to-do list.

Product Increment — the sum of all the backlog items that have been completed according to the Definition of Done, accepted, and delivered so far. It's the done, usable deliverable added on top of every increment that came before it, and it's thoroughly verified to ensure all the increments actually work together as one coherent whole — not as separate, disconnected pieces that happen to ship in the same release. The team creates the increment by working as a self-organizing unit to accomplish the Sprint Goal.

Scrum of Scrums — when multiple Scrum teams are working on the same product, each team sends a representative to a Scrum of Scrums to coordinate dependencies, surface cross-team impediments, and keep everyone's view of the shared product aligned — the same transparency goal the three core artifacts serve, just extended across team boundaries instead of within one team.

Study focus: PMI likes pairing each artifact with its progress commitment directly — Product Backlog ↔ Product Goal, Sprint Backlog ↔ Sprint Goal, Increment ↔ Definition of Done. Mixing up which commitment belongs to which artifact is the single most common wrong-answer trap in this topic.