Managing Scrum Artifacts: Product Backlog, Sprint Backlog, and Increment
Managing Scrum Artifacts: A Comprehensive Guide for PSM II
Understanding how to manage Scrum artifacts is a cornerstone competency for any advanced Scrum Master. In the PSM II exam, you are expected to go beyond definitions and demonstrate a deep understanding of how these artifacts create transparency, enable inspection, and drive adaptation. This guide explores the Product Backlog, Sprint Backlog, and Increment in detail, covering why they matter, how they work, and how to confidently answer exam questions about them.
Why Managing Scrum Artifacts Is Important
Scrum artifacts represent work or value. They are designed to maximize transparency of key information so that everybody has the same understanding of the artifact. Without proper management of these artifacts, Scrum Teams lose their ability to inspect and adapt effectively, which is the very foundation of empirical process control.
Each artifact contains a commitment that provides information to enhance transparency and focus against which progress can be measured:
- The Product Backlog has the Product Goal
- The Sprint Backlog has the Sprint Goal
- The Increment has the Definition of Done
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders. When artifacts are poorly managed, decisions are made on incomplete or inaccurate information, leading to waste, misalignment, and erosion of stakeholder trust.
What Are the Scrum Artifacts?
1. Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
Key characteristics:
- It is never complete. It evolves as the product and the environment in which it will be used evolves.
- It is ordered, not just prioritized. The Product Owner determines the ordering based on value, risk, dependencies, need, and other factors.
- It is owned by the Product Owner, though the Product Owner may delegate the work of managing it to the Developers. Regardless of who does it, the Product Owner remains accountable.
- Product Backlog refinement is the act of breaking down and further defining items into smaller, more precise items. This is an ongoing activity to add details such as description, order, and size.
- The Product Goal describes a future state of the product and serves as a long-term objective for the Scrum Team. The Product Goal is in the Product Backlog, and the rest of the Product Backlog emerges to define what will fulfill the Product Goal.
2. Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how).
Key characteristics:
- It is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint.
- It is updated throughout the Sprint as more is learned. It should have enough detail that the Developers can inspect their progress in the Daily Scrum.
- The Sprint Goal is the single objective for the Sprint. It provides coherence, focus, and flexibility to the Developers regarding the exact work needed. The Sprint Goal is created during Sprint Planning and then added to the Sprint Backlog.
- Only the Developers can change the Sprint Backlog during the Sprint. If new work is needed, the Developers add it to the Sprint Backlog. If work is no longer deemed necessary, it is removed.
- The Sprint Goal cannot be changed once the Sprint starts. However, the scope of work (the selected Product Backlog items and the plan) can be negotiated and clarified with the Product Owner without changing the Sprint Goal.
3. Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
Key characteristics:
- Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review, thus supporting empiricism.
- An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
- Work cannot be considered part of an Increment unless it meets the Definition of Done.
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
- If the Definition of Done for an Increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
- If there are multiple Scrum Teams working on the same product, they must mutually define and comply with the same Definition of Done.
How Managing Scrum Artifacts Works in Practice
As an advanced Scrum Master, managing artifacts goes far beyond ensuring they exist. It involves:
Ensuring Transparency:
- Coaching the Product Owner on effective Product Backlog management techniques, such as writing clear items, maintaining proper ordering, and ensuring the Product Goal is well understood by all.
- Helping the Developers maintain a visible and up-to-date Sprint Backlog that genuinely reflects the current state of progress.
- Facilitating conversations around the Definition of Done to ensure everyone understands and adheres to it, and advocating for strengthening it over time.
Enabling Inspection:
- Helping stakeholders understand the Product Backlog and its current state so they can provide meaningful feedback.
- Coaching the Developers to use the Sprint Backlog as an inspection tool during the Daily Scrum to assess progress toward the Sprint Goal.
- Ensuring that Increments are truly Done and usable, so that inspection during the Sprint Review is based on real, working product rather than incomplete work.
Driving Adaptation:
- Supporting the Product Owner in reordering the Product Backlog based on new learning, feedback, and market changes.
- Helping the team adapt their Sprint Backlog when they discover the original plan is no longer valid, while protecting the Sprint Goal.
- Championing improvements to the Definition of Done as the team matures, which directly improves the quality and usability of future Increments.
Common Misunderstandings to Avoid
- The Product Backlog is not a requirements document. It is an evolving, living artifact.
- The Sprint Backlog belongs to the Developers, not the Scrum Master or Product Owner.
- An Increment does not only happen at the end of a Sprint. Multiple Increments can be created within a single Sprint, and they can be released at any time.
- The Definition of Done is not the same as acceptance criteria. Acceptance criteria are specific to individual Product Backlog items. The Definition of Done applies to all Increments and defines the quality standard.
- The Sprint Goal is not a list of items to complete. It is a coherent objective that gives the Developers flexibility in how they achieve it.
- The Product Owner does not have to write every Product Backlog item personally. They can delegate the work but remain accountable for the Product Backlog.
Exam Tips: Answering Questions on Product Backlog, Sprint Backlog, and Increment
Tip 1: Know the Commitments
Every artifact has a commitment. If a question asks about transparency, focus, or progress measurement, think about Product Goal, Sprint Goal, and Definition of Done. Questions often test whether you can connect the right commitment to the right artifact.
Tip 2: Understand Accountability vs. Responsibility
The Product Owner is accountable for the Product Backlog but may delegate work to others. The Developers own the Sprint Backlog. The entire Scrum Team is responsible for adhering to the Definition of Done. PSM II questions frequently test these nuances. If an answer choice suggests the Scrum Master manages the Product Backlog or that the Product Owner dictates the Sprint Backlog to Developers, it is likely wrong.
Tip 3: Think Empirically
When a question presents a scenario about artifacts, ask yourself: Does this answer maximize transparency? Does it enable inspection? Does it support adaptation? The correct answer in PSM II almost always aligns with empirical process control principles.
Tip 4: Watch for Scope vs. Goal Confusion
A very common exam trap involves the difference between the Sprint Goal and the Sprint scope. The Sprint Goal is fixed once the Sprint begins, but the scope (selected Product Backlog items and the plan) can be negotiated and clarified with the Product Owner. If a question asks what happens when new information emerges during a Sprint, the correct approach usually involves negotiating scope while protecting the Sprint Goal.
Tip 5: Multiple Increments per Sprint
Remember that the Scrum Guide explicitly states that multiple Increments may be created within a Sprint and that the Increment can be delivered before the Sprint ends. Any answer that suggests an Increment can only be released at the Sprint Review is incorrect.
Tip 6: Definition of Done Is Non-Negotiable
If work does not meet the Definition of Done, it cannot be considered part of the Increment. If an exam question presents a scenario where a team wants to release partially done work or where a stakeholder pressures the team to relax the Definition of Done, the correct answer will protect the integrity of the Definition of Done.
Tip 7: Look for the Scrum Master as a Servant-Leader
In questions about artifact management, the Scrum Master's role is typically one of coaching, facilitating, and removing impediments—not controlling or managing the artifacts directly. If an answer choice positions the Scrum Master as the person who updates, orders, or owns an artifact, it is almost certainly incorrect.
Tip 8: Scenarios Over Definitions
PSM II is a professional-level exam. Questions will rarely ask you to simply define an artifact. Instead, they will present complex scenarios and ask you to apply your understanding. Practice by thinking through real-world situations: What would you do if the Product Backlog has hundreds of items and no clear Product Goal? What if the Developers are not updating the Sprint Backlog? What if the team has an inconsistent Definition of Done? The ability to reason through these scenarios using Scrum principles is what separates PSM II from PSM I.
Tip 9: Consider the Whole System
Artifacts do not exist in isolation. The Product Backlog feeds the Sprint Backlog during Sprint Planning. The Sprint Backlog drives the creation of the Increment. The Increment is inspected at the Sprint Review, which may lead to changes in the Product Backlog. Understanding this flow and the interconnections between artifacts will help you answer complex questions that span multiple Scrum events and roles.
Tip 10: Default to the Scrum Guide
When in doubt, go back to the Scrum Guide. The PSM II exam is based on the Scrum Guide, and while it tests application and understanding at a deeper level, the foundational truths are always rooted in the guide. If an answer contradicts anything in the Scrum Guide, eliminate it.
Summary
Managing Scrum artifacts effectively is essential for creating transparency, enabling inspection, and driving adaptation. The Product Backlog, Sprint Backlog, and Increment—along with their respective commitments of Product Goal, Sprint Goal, and Definition of Done—form the backbone of empirical process control in Scrum. For the PSM II exam, go beyond memorizing definitions. Understand the why behind each artifact, know who is accountable, recognize how they interconnect, and practice applying this knowledge to real-world scenarios. This depth of understanding will not only help you pass the exam but will make you a more effective Scrum Master in practice.
