HKSM

Applicable Contracts are the agreements, statements of work, policies, and service terms that legally bind the Scrum project to customers, vendors, or partners. They set constraints and obligations that affect scope, acceptance, delivery cadence, compliance, and payment. In SBOK, they act as inputs to planning and delivery and as outputs when new agreements are negotiated during the project.

Key Points

• Acts as both an input and an output across Scrum processes, especially during initiation, planning, and release activities.
• Includes contracts, SOWs, MSAs, licenses, SLAs, and compliance obligations relevant to the product and delivery.
• Influences the product backlog, Definition of Done, acceptance criteria, and release planning.
• Choice of pricing model (fixed-price, time-and-materials, capped T&M, cost-reimbursable) affects risk sharing and estimation.
• Contract clauses guide how changes are handled in the backlog and how acceptance and payments are triggered.
• Should be visible to the Product Owner and Scrum Master and stored in an accessible project repository.

Purpose

Applicable Contracts clarify obligations, rights, and service levels so the Scrum Team can plan work responsibly and meet stakeholder expectations. They reduce legal and financial risk, align incentives, and provide a clear path for change, acceptance, and payments.

In agile settings, well-structured contracts enable incremental delivery, regular feedback through Sprint Reviews, and adaptive scope management via the product backlog.

Key Terms & Clauses

• Scope and Change Handling: Links scope to the product backlog and defines how backlog changes affect cost, schedule, and acceptance.
• Pricing and Payment: Fixed-price, T&M, capped T&M, or milestone/sprint-based payments tied to accepted increments.
• Acceptance Criteria: Objective, testable conditions for user stories, releases, or increments and who signs off.
• Delivery Cadence and Milestones: Expected sprint or release frequency and any mandatory delivery dates.
• Service Levels and Nonfunctional Requirements: Performance, availability, security, and support response times.
• Intellectual Property and Licensing: Ownership of deliverables, open-source use, and reuse rights.
• Compliance and Audit: Data protection, industry regulations, and audit access.
• Termination and Dispute Resolution: Exit terms, notice periods, and escalation paths.

How to Develop/Evaluate

Creation often occurs during initiation or procurement activities and may continue as new vendors join. Evaluation ensures the team understands constraints and aligns backlog items and acceptance criteria with contractual obligations.

• Identify all existing agreements (MSA, SOW, SLAs, licenses) and confirm applicability to the current product scope.
• Choose contract models that fit uncertainty: prefer agile-friendly terms like capped T&M or fixed-price per release/sprint with clear acceptance.
• Define measurable acceptance criteria and trace them to stories and releases.
• Include flexible change mechanisms that integrate with backlog refinement and prioritization.
• Review with legal, procurement, Product Owner, and key stakeholders to resolve gaps, risks, and compliance issues.
• Baseline and version-control the final documents; record how each clause maps to backlog items or Definition of Done elements.

How to Use

• Backlog Management: Derive contractual constraints and nonfunctional requirements as backlog items and acceptance criteria.
• Estimation and Planning: Consider pricing model and SLAs when sizing, forecasting velocity, and planning releases.
• Definition of Done: Incorporate required tests, documentation, security reviews, and acceptance steps.
• Sprint Review: Demonstrate increments against contractual acceptance criteria and record formal sign-offs when required.
• Change Control: Use the contract change clause to negotiate scope/cost impacts while reprioritizing the backlog.
• Risk Management: Log contract-related risks (penalties, deadlines, compliance) and plan mitigations.
• Release and Handover: Align contractual milestones with release schedules and trigger payments upon acceptance.

Example Snippet

Sample language that supports agile delivery:

• Scope is delivered incrementally via time-boxed sprints. Payment of USD X per accepted sprint increment, subject to meeting the stated acceptance criteria for selected user stories.
• Changes are managed through the product backlog. The Product Owner may reprioritize items; material scope increases will be handled via the contract change clause with agreed price/time adjustments.
• Acceptance occurs at Sprint Review based on objective tests. Nonfunctional requirements (performance, security) are part of the Definition of Done.

Risks & Tips

• Risk: Fixed-scope contracts lock requirements early and create churn. Tip: Use outcome-based milestones or capped T&M with clear acceptance to allow adaptation.
• Risk: Ambiguous acceptance criteria cause disputes and payment delays. Tip: Make acceptance measurable and trace each criterion to stories and tests.
• Risk: Penalty-heavy SLAs drive unsafe shortcuts. Tip: Negotiate balanced SLAs and include quality gates in the Definition of Done.
• Risk: Contract change board conflicts with backlog-driven change. Tip: Align the change clause with backlog refinement and release planning cadence.
• Risk: Hidden licensing or data obligations surface late. Tip: Involve legal and security early; add compliance tasks to the backlog.

PMP/SCRUM Example Question

A Scrum Team delivering under a fixed-price SOW discovers valuable new requirements mid-sprint. The contract ties payment to acceptance of a release-level backlog. What should the Product Owner do next?

1. Approve the new scope immediately because agile welcomes change.
2. Submit a contract change using the change clause while reprioritizing the backlog.
3. Ask the Scrum Master to extend the sprint to include the new work.
4. Cancel the sprint and start a new one with the added scope.

Correct Answer: B — Submit a contract change using the change clause while reprioritizing the backlog.

Explanation: The contract governs acceptance and payment. The Product Owner should adjust the backlog and, if scope materially changes cost or time, trigger the contractual change mechanism rather than unilaterally adding work or altering the sprint timebox.