Working Deliverables

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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Launch your Agile career!

HK School of Management helps you learn Agile and Scrum with practical playbooks, AI-powered prompts, and real-world workflows for planning and delivery. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More