HKSM

Key Points

• Formally approved by the Product Owner after the Sprint Review demonstration and validation.
• Must satisfy the Definition of Done, acceptance criteria, and relevant nonfunctional and compliance requirements.
• Output of Demonstrate and Validate Sprint; primary input to Ship Deliverables and Obtain Customer Acceptance.
• Documented with clear evidence such as test results, acceptance notes, and traceability to user stories.
• Rejected items are returned to the Product Backlog with updated details or defects; only accepted work proceeds to release planning.
• May represent a subset of the Product Backlog packaged into a potential release or increment.

Purpose

Accepted Deliverables provide a clear, auditable handoff from development to release activities. They ensure only fit-for-use increments flow forward, reducing rework and improving stakeholder confidence.

This artifact aligns the team, Product Owner, and stakeholders on what is ready to ship and what needs more work.

Key Terms & Clauses

• Definition of Done - Shared checklist that defines completeness across quality, testing, documentation, and compliance.
• Acceptance Criteria - Story-specific conditions that must be met for the Product Owner to approve the item.
• Verification vs. Validation - Verification checks the increment against criteria; validation confirms it meets stakeholder needs.
• Traceability - Link from accepted deliverables back to epics, user stories, and tests for transparency.
• Release Readiness - Evidence that accepted items can be safely shipped or deployed.

How to Develop/Evaluate

Evaluation happens in the Sprint Review within the Demonstrate and Validate Sprint process. The team presents the completed increment, and the Product Owner determines acceptance.

1. Prepare evidence: automated test results, manual test reports, demos, and DoD checklist.
2. Demonstrate the increment end-to-end, focusing on user stories and acceptance criteria.
3. Validate nonfunctional needs such as performance, security, accessibility, and compliance.
4. Address questions, log defects, and clarify any scope misunderstandings.
5. Record the decision: accepted or not accepted, with notes and links to artifacts.
6. Update the Product Backlog for any rejected items, defects, or new change requests.

How to Use

Once accepted, the increments flow into release and operational processes.

• Input to Ship Deliverables for packaging, deployment planning, and release notes.
• Reference for Obtain Customer Acceptance and any pilot or UAT activities.
• Update metrics such as velocity, burn charts, and cumulative flow to reflect accepted scope.
• Feed into Retrospect Sprint to discuss quality, review effectiveness, and acceptance patterns.
• Inform stakeholder communications and roadmap updates with clear status of shipped value.

Example Snippet

Simple acceptance record you might store in your tooling:

• Story: US-245 - As a user, I can search items by keyword.
• Acceptance Criteria: exact match, partial match, response time under 2 seconds, audit logging.
• DoD: unit tests 90%+, integration tests passed, security scan clean, docs updated.
• Evidence: CI pipeline #874 passed; manual test report TR-112; performance test avg 1.4s.
• Decision: Accepted by Product Owner on 2025-06-03; ready for Ship Deliverables.

Risks & Tips

• Risk: Ambiguous acceptance criteria lead to disputes; write criteria when creating user stories and refine during backlog grooming.
• Risk: Accepting with unresolved critical defects increases release risk; ensure the DoD prohibits it.
• Risk: Environment mismatch causes false positives; validate in production-like environments.
• Tip: Keep a lightweight acceptance template and link it to test artifacts for traceability.
• Tip: Include nonfunctional checks in the DoD to avoid late surprises during release.
• Tip: Timebox demonstrations and focus on outcomes tied to user value and criteria.

PMP/SCRUM Example Question

During Sprint Review, the team demonstrates an increment that meets all story acceptance criteria, but the performance benchmark in the Definition of Done fails under load. What should the Product Owner do regarding acceptance?

1. Accept the increment because stakeholders approved the demo.
2. Accept the increment and log the performance gap as technical debt.
3. Do not accept the increment until the Definition of Done is fully met.
4. Mark it accepted for Ship Deliverables and plan to hotfix after release.

Correct Answer: C — Do not accept the increment until the Definition of Done is fully met.

Explanation: Acceptance requires meeting both acceptance criteria and the Definition of Done. A performance failure means the increment is not complete and should not be accepted or shipped.