HKSM

Working Deliverables are the completed, integrated product components produced in a sprint that meet the teams Definition of Done and are ready to be shown to stakeholders. They are the output of creating deliverables and the input to demonstration and validation, leading to accepted or unacceptable deliverables.

Key Points

• Output of Create Deliverables and input to Demonstrate and Validate Sprint.
• Must satisfy the Definition of Done and each storys acceptance criteria.
• Represent a potentially shippable increment when combined across completed stories.
• Integrated, tested, and usable by a customer or end user without major rework.
• Traceable to Product Backlog Items and clearly documented with test evidence.
• Items not meeting criteria are not Working Deliverables and return to the backlog.

Purpose

Working Deliverables provide a tangible, inspectable increment for stakeholders during the sprint review. They enable transparency, meaningful feedback, and clear acceptance decisions that drive release planning and future sprint scope.

They also serve as a baseline for discussing quality, process improvements, and readiness for deployment in the release processes.

Key Terms & Clauses

• Definition of Done: The shared checklist that must be satisfied for any item to be considered complete and demo-ready.
• Acceptance Criteria: Story-specific conditions the Product Owner uses to accept or reject the outcome.
• Potentially Shippable Increment: The integrated sum of all Working Deliverables in the sprint that could be released.
• Traceability: Each deliverable links back to a Product Backlog Item and its acceptance criteria and tests.
• Integration and Test Evidence: Code, configuration, test results, and documentation that prove completeness.

How to Develop/Evaluate

Teams develop Working Deliverables by selecting stories in sprint planning, breaking them into tasks, and building them with continuous integration and automated testing. They perform peer reviews, validate acceptance criteria, and ensure nonfunctional requirements are verified.

• Design and build tasks from the sprint backlog and integrate frequently.
• Run unit, integration, and functional tests and fix defects immediately.
• Check the Definition of Done and acceptance criteria using a visible checklist.
• Prepare demo data, environments, and evidence of test results.
• Record completion status and link artifacts in the teams toolset.

How to Use

During Demonstrate and Validate Sprint, the team showcases Working Deliverables to the Product Owner and stakeholders. The Product Owner accepts or rejects each item based on acceptance criteria and DoD.

• Accepted items become part of the increment and can be queued for release.
• Unacceptable items are returned to the Product Backlog with clear notes for rework.
• Capture feedback as new or updated backlog items for future sprints.
• Use results to inform release planning and metrics such as velocity and forecast.
• Discuss lessons learned in the sprint retrospective to refine the DoD and practices.

Example Snippet

In Sprint 6, the team completes three stories: search, filter, and export. All three pass unit and integration tests, meet performance thresholds, and include updated user help and logging.

At the sprint review, stakeholders validate behavior against acceptance criteria. Two stories are accepted; the export story fails a specific edge case and is returned to the backlog with a new task for the gap.

Risks & Tips

• Risk: Declaring items done without integration or acceptance tests. Tip: Enforce CI and a strict DoD checklist.
• Risk: Environment drift causing demo failures. Tip: Use reproducible environments and test data.
• Risk: Hidden work like documentation or security checks deferred. Tip: Include nonfunctional criteria in the DoD.
• Risk: Partial acceptance by pressure. Tip: The Product Owner should only accept items that meet all criteria.
• Risk: Late discovery of dependencies. Tip: Refine backlog early and slice stories to reduce external blockers.

PMP/SCRUM Example Question

During the sprint review, one story compiles and passes unit tests but fails a key acceptance criterion. What should happen to this item as part of handling Working Deliverables?

1. Mark it accepted because coding is complete and move it to release.
2. Defer the acceptance decision to the Scrum Master for resolution.
3. Do not accept it; return it to the Product Backlog with notes for rework.
4. Accept it now and plan to fix the gap in the next sprint.

Correct Answer: C — Do not accept it; return it to the Product Backlog with notes for rework.

Explanation: A Working Deliverable must satisfy the DoD and acceptance criteria. If it fails, it is not accepted and should be updated or re-planned as backlog work.