Understanding and Applying the Scrum Framework

The Definition of Done (DoD) specifies the shared understanding of quality standards that each Product Backlog item must meet before it can be considered complete.

This is the most accurate answer because:

1. The DoD is fundamentally about establishing a shared understanding across the Scrum Team of what 'Done' means
2. It focuses on quality standards and criteria that must be met
3. It applies to Product Backlog items selected for a Sprint
4. It determines when work is complete and potentially releasable

Why the other answers are incorrect:

The second option incorrectly conflates the Definition of Done with acceptance criteria. While both are important, they serve different purposes. The DoD is about quality standards and completeness that apply to all items, whereas acceptance criteria are specific to individual Product Backlog items and are indeed defined by the Product Owner for business value verification. These are separate concepts that should not be merged.

The third option is too narrow and prescriptive. While the DoD may include technical aspects, it is not specifically about 'work completion' with emphasis on 'technical dependencies and integration points with external systems.' The DoD is broader than just technical considerations and focuses on quality standards more generally.

The fourth option misrepresents the purpose of the Definition of Done. While the DoD may indirectly influence velocity observations, its primary purpose is not to guide velocity and capacity planning. The DoD exists to ensure quality and a shared understanding of completeness, not as a planning tool for forecasting future Sprint capacity.

The Daily Scrum is time-boxed to 15 minutes regardless of Sprint duration.

According to the Scrum Guide, the Daily Scrum is a 15-minute event for the Developers of the Scrum Team. This time-box is fixed and does not change based on the length of the Sprint. Whether you have a one-week Sprint or a one-month Sprint, the Daily Scrum remains 15 minutes.

The purpose of this fixed time-box is to promote focus and efficiency. The Daily Scrum is meant to be a quick synchronization event where Developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. By keeping it consistently at 15 minutes, the team maintains discipline and learns to communicate effectively within this constraint.

Why the other answers are incorrect:

The idea that the Daily Scrum duration should be proportional to Sprint length contradicts the Scrum Guide. Making it shorter for shorter Sprints would reduce the already brief opportunity for daily inspection and adaptation.

Scaling the Daily Scrum from 10 to 20 minutes based on Sprint length is not supported by Scrum framework. This would unnecessarily complicate a simple, consistent practice.

Allocating 15 minutes per Sprint week (resulting in 30-60 minute Daily Scrums) would make the event far too long and defeat its purpose as a quick daily synchronization. This would likely lead to the event becoming a detailed status meeting rather than a focused planning session for the next 24 hours.

The primary purpose of a Sprint in Scrum is to create a Done Increment that moves toward the Product Goal within a fixed time-box.

This is the correct answer because:

• Sprints are designed to create Done Increments that progressively move the product closer to achieving the Product Goal
• The time-boxed nature (typically 1-4 weeks) ensures predictable progress and opportunities for inspection and adaptation
• Each Sprint should result in at least one usable Increment that meets the Definition of Done
• The focus is on incremental progress toward the Product Goal, not necessarily completing everything or shipping to customers

Why the other answers are incorrect:

The second option incorrectly suggests that ALL committed Product Backlog items must be delivered. In Scrum, the Sprint Goal is the commitment, not all items. The Developers forecast what they can complete, but the focus is on achieving the Sprint Goal and creating a Done Increment, not necessarily completing every selected item.

The third option incorrectly states that the purpose is to create a release that can be shipped to customers. While Increments should be potentially releasable and meet the Definition of Done, shipping to customers is not the primary purpose of every Sprint. The Product Owner decides when to release, which may or may not happen every Sprint.

The fourth option incorrectly claims that the entire Product Backlog should be completed within a Sprint. This is unrealistic and contrary to Scrum's iterative nature. The Product Backlog is typically an evolving list that grows and changes, and completing it entirely in one Sprint would defeat the purpose of empiricism and adaptation.