Scrum is a lightweight framework that helps organizations generate value through adaptive solutions for complex problems. It employs an iterative and incremental approach, allowing teams to deliver working components frequently and incorporate feedback quickly. This structure relies on empirical process control, where knowledge comes from experience and decisions are based on observation. The three pillars of empiricism—transparency, inspection, and adaptation—are continuously supported by the framework’s components.
What Are Scrum Artifacts?
Scrum artifacts are specific representations of work or value designed to maximize the transparency of information. They provide a common reference point for the Scrum Team and stakeholders regarding the work being performed and the progress being made. By making this information visible, artifacts allow for timely inspection and subsequent adaptation of the work process and measurement of value produced.
Artifact 1: The Product Backlog
The Product Backlog serves as the single authoritative source of all work needed to be done on the product. It is an ordered list containing everything from features, functions, requirements, and enhancements, to fixes that are necessary to improve the product. The Product Owner is accountable for the content, ordering, and availability of this backlog, making it a living, evolving roadmap for the product’s future.
Items at the top of the backlog are typically more refined and ready for immediate implementation, while items lower down remain larger and less detailed. Product Backlog refinement (PBR) involves breaking down large items into smaller, precise ones, adding detail, and ensuring proper estimations are in place. This refinement ensures that items selected for a future Sprint are Detailed appropriately, Estimated, Emergent, and Prioritized—the DEEP characteristics of a healthy backlog.
The backlog is dynamic and continuously changes as the market evolves, customer needs shift, and the team learns more about the product. New items are added, existing items may be removed or re-ordered, and the level of detail on items is adjusted as they move closer to the top. Maintaining this flow connects the team’s current work directly to the long-term vision of the product.
Artifact 2: The Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the current Sprint, combined with the actionable plan for delivering the Increment and achieving the Sprint Goal. Created by the Developers during Sprint Planning, it represents their forecast of the functionality they can deliver during that specific timebox. This artifact serves as a highly visible, real-time plan for the Developers.
The Sprint Backlog details not only what work will be done but also how that work will be accomplished. It is not static; as the Developers work through the Sprint, they may need to adjust the tasks and the plan to address unexpected challenges or new information. Only the Developers can modify the Sprint Backlog during the Sprint, reflecting the emergent nature of the work.
This artifact fundamentally differs from the Product Backlog because it is a commitment to a specific outcome over a short period, rather than a long-term list of possibilities. The Product Backlog contains items that could be done, whereas the Sprint Backlog contains the specific items that will be done in the current iteration, along with the detailed steps to realize them. Its existence ensures that the team maintains focus on the defined Sprint Goal throughout the entire cycle.
Artifact 3: The Product Increment
The Product Increment is the culmination of all completed Product Backlog items from the current Sprint, added to the sum of all previous Increments. It represents a concrete step toward the Product Goal and must be in a usable, potentially releasable condition. This means the Increment meets all the standards necessary for immediate deployment to end-users.
For an item to be considered complete and part of the Increment, it must adhere to the Definition of Done (DoD). The Definition of Done is the formal description of the state of the Increment when it meets the required quality measures for the product. This shared understanding of quality is established by the Scrum Team and ensures consistency and rigor across all work produced.
If a Product Backlog item does not meet the Definition of Done, it cannot be included in the Increment and must be returned to the Product Backlog for future consideration. The DoD guarantees that every piece of functionality added to the product maintains a minimum level of quality and integration. The Increment is the embodiment of value delivered and is the primary object inspected during the Sprint Review.
The Three Commitments Guiding the Artifacts
Each of the three Scrum artifacts is paired with a specific commitment that brings focus and a long-term objective. These commitments serve as promises the Scrum Team makes to its stakeholders, helping to structure the team’s planning and execution. They provide context for effective inspection and adaptation of the work.
A. Commitment for the Product Backlog: The Product Goal
The Product Goal is the long-term objective for the Scrum Team, describing a future state of the product that the team plans to achieve. The Product Backlog is the list of things that, if completed, will achieve this goal, making the goal a target for the entire backlog. The team focuses all its efforts on fulfilling the current Product Goal before moving on to the next strategic objective.
B. Commitment for the Sprint Backlog: The Sprint Goal
The Sprint Goal is the single, short-term objective for the Sprint, providing the Developers with flexibility regarding the exact work needed to achieve it. It is created during Sprint Planning and serves as a guiding purpose for the Developers throughout the iteration. The Sprint Goal helps the team understand why they are building the Increment and allows them to negotiate scope if unexpected challenges arise.
C. Commitment for the Increment: The Definition of Done
The Definition of Done (DoD) is the commitment that ensures the quality of the Increment produced by the Scrum Team. As established previously, it is the formal quality standard that all completed work must satisfy before it can be considered part of the usable and potentially releasable Increment. The DoD helps ensure that every piece of functionality is integrated and tested to the required level.
Ensuring Artifact Transparency and Inspection
The existence of the artifacts enables the Scrum Team to operate empirically. Transparency is achieved when the artifacts are visible to all involved parties, allowing everyone to see the current state of the product, the plan for the Sprint, and the remaining work. This visibility ensures that decisions are based on the observable reality of the work.
Inspection occurs when the Scrum Team and stakeholders review the artifacts at specific points in the process to detect undesirable variances. For example, the Product Backlog is inspected and adapted continuously during refinement, as well as during Sprint Planning and the Sprint Review. The Sprint Backlog is inspected daily during the Daily Scrum to assess progress toward the Sprint Goal.
The Increment is inspected during the Sprint Review to gather feedback and determine if adaptation is necessary for the Product Backlog. By making all work visible through these three artifacts, deviations from the desired outcome become apparent quickly. This immediacy allows the Scrum Team to make timely adaptations to their process or their product.