Working Deliverables Agreement
A concise, shared agreement that specifies the acceptance criteria, Definition of Done, quality standards, and sign-off conditions for the sprint’s working deliverables. Co-created by the Product Owner and Scrum Team and confirmed by key stakeholders, it guides development, review, and acceptance. It serves as an input to validate increments and an output that evolves across sprints.
Key Points
- Aligns the Product Owner, Scrum Team, and stakeholders on what makes deliverables acceptable.
- Combines acceptance criteria per user story with team Definition of Done and quality expectations.
- Version-controlled and refined throughout the release and each sprint.
- Used during Develop/Build, Demonstrate and Validate Sprint, and Accept Deliverables processes.
- Links deliverables to test cases, evidence, and sign-off authority.
- Reduces rework by clarifying non-functional and compliance needs early.
Purpose
The agreement sets clear, testable expectations for the increment so the team can build the right thing and stakeholders can verify outcomes quickly. It establishes the objective basis for acceptance, shortening feedback loops and improving predictability.
By capturing criteria up front and refining as needed, it lowers ambiguity, supports risk-based testing, and accelerates sprint review decisions.
Key Terms & Clauses
- Scope boundary: what is in scope for this sprint increment and what is explicitly out of scope.
- Acceptance criteria: per-user-story conditions of satisfaction that are testable.
- Definition of Done: shared standards for completeness, quality, integration, and documentation.
- Non-functional requirements: performance, security, usability, reliability, and compliance thresholds.
- Test evidence: required artifacts such as automated test results, screenshots, logs, and checklists.
- Sign-off authority and procedure: who approves, how evidence is reviewed, and turnaround time.
- Traceability: mapping from product backlog items to tests and acceptance outcomes.
- Change handling: how new information or scope changes are routed via the product backlog.
How to Develop/Evaluate
Develop the agreement collaboratively in Release Planning and refine in Sprint Planning. Start from product backlog items, organizational standards, Definition of Done, and regulatory needs.
- Draft acceptance criteria for each user story following INVEST and SMART patterns.
- Align with the team’s Definition of Done and include measurable non-functional thresholds.
- Identify test cases and evidence required to prove each criterion.
- Document sign-off roles and decision rules for the sprint review.
- Version and store in a visible repository linked to backlog items.
Evaluate with a quick checklist: Are criteria testable and unambiguous? Are NFRs measurable? Is sign-off clear? Is it feasible within the sprint timebox?
How to Use
During development, the team uses the agreement to guide tasking, test-first practices, and quality gates. The Scrum Master ensures visibility and helps resolve ambiguities early.
- Input to Create Deliverables: informs design, coding standards, and testing scope.
- Input to Demonstrate and Validate Sprint: frames the sprint review agenda and evidence.
- Basis for Accept Deliverables: drives the accept or reject decision for user stories.
- Feedback to Retrospect Sprint: gaps discovered feed updates to DoD and future agreements.
- Link to Ship Deliverables: ensures shipped increments meet documented criteria and compliance.
Example Snippet
Example elements for a single user story:
- Story: As a user, I can reset my password via email.
- Acceptance criteria: Token expires in 15 minutes; email delivered within 30 seconds; success and error messages localized; audit entry recorded.
- Definition of Done: Unit tests 90% for changed code; integration tests pass; security scan clean; documentation updated.
- Evidence: Automated test report, mail log excerpt, localization screenshots, audit log entry ID.
- Sign-off: Product Owner approves during sprint review after demo and evidence check.
Risks & Tips
- Risk: Vague criteria lead to debate and delays. Tip: write measurable, testable statements.
- Risk: Over-specification limits discovery. Tip: focus on outcomes, not internal design.
- Risk: Missing non-functional needs cause late rework. Tip: add NFR thresholds early.
- Risk: Criteria drift mid-sprint. Tip: handle changes via backlog refinement and re-planning.
- Risk: Hidden sign-off authority. Tip: name approvers and timeframes in the agreement.
- Risk: Stale documents. Tip: version and review at each sprint planning and review.
PMP/SCRUM Example Question
During the sprint review, stakeholders question whether several user stories are acceptable. Which artifact should the Scrum Master point to as the primary basis for acceptance decisions?
- Sprint Goal.
- Release burnup chart.
- Working Deliverables Agreement.
- Task board.
Correct Answer: C — Working Deliverables Agreement
Explanation: The agreement consolidates acceptance criteria, Definition of Done, and sign-off rules used to validate and accept deliverables during the sprint review. The other artifacts do not provide testable acceptance conditions.
HKSM