Skip to main content
The Scrums.com API is planned and not yet publicly available. Endpoints and behaviour are subject to change before release.

Overview

ODS (On-Demand Sprints) is outcome-based delivery. You define what needs to exist — a working feature, a fixed integration, a delivered audit, a shipped component — and Scrums.com delivers it within a defined timeframe at a fixed commercial commitment. ODS is not sprint tooling. You are not managing a team or tracking a backlog. You are purchasing a defined outcome. The scope is fixed, the price is fixed, and completion is verified against acceptance criteria. When an ODS scope is confirmed, the platform creates an active Service Line with execution_model: timeboxed_outcome and billing_model: fixed_scope. The engagement is tracked as discrete cycles. Deliverables must be formally accepted to close the Service Line.

Core Concepts

Requests

A request is the starting point: a description of the outcome you need and the constraints around it (timeline, budget, acceptance criteria). Scrums.com reviews the request, produces a scoped proposal, and presents it for confirmation.

Scopes

A scope is the confirmed engagement specification: the deliverables, the acceptance criteria, the timeline, and the fixed price. You confirm the scope to activate the engagement.

Cycles

A cycle is a time-boxed delivery period within an ODS scope. Complex outcomes may be broken into multiple cycles with interim deliverables. Each cycle has a planned end date and a set of deliverable items.

Deliverables and acceptance

When a cycle completes, deliverables are surfaced via the API for formal review and acceptance. You either accept (releases payment and may trigger next cycle) or reject (triggers a remediation cycle at no additional cost, within scope). This is the key distinction from managed delivery: you are not managing the work. You are reviewing the output and making a binary acceptance decision.

Endpoints

POST /v1/capabilities/ods/requests

Submit an ODS outcome request.

Request

Response

Notes

  • Status moves to scoped when Scrums.com has produced a proposal. You receive a ods.request.scoped event.
  • If budget or timeline cannot be accommodated, the request moves to requires_negotiation and the account team will contact you.

GET /v1/capabilities/ods/requests/

Retrieve a request with current status and any attached scope proposal.

Response

GET /v1/capabilities/ods/scopes/

Retrieve the full scope proposal.

Response

POST /v1/capabilities/ods/scopes/

Confirm a scope to activate the engagement and create the Service Line.

Request

Response

GET /v1/capabilities/ods/cycles/

Get current cycle status, progress, and deliverable states.

Response

GET /v1/capabilities/ods/deliverables

List deliverables ready for acceptance review.

Request

POST /v1/capabilities/ods/deliverables//accept

Formally accept a deliverable.

Request

Notes

  • Setting accepted: false triggers a remediation cycle. Include a rejection_reason explaining what criteria were not met.
  • Final acceptance of the last deliverable closes the Service Line and triggers the final payment.

Common Workflows

Full ODS engagement lifecycle

Objects

ODS Request

Scope

Best Practices

  • Write acceptance criteria before confirming a scope. Vague acceptance criteria lead to disputes. If the scope proposal has weak criteria, reject it and ask for specifics before confirming.
  • Do not try to manage the delivery. ODS is not a managed engagement. Your role is to review deliverables and make acceptance decisions. Attempting to direct the team mid-cycle undermines the fixed-scope model.
  • Use rejection_reason precisely. When rejecting a deliverable, specify exactly which acceptance criteria were not met, with evidence. Generic rejections (“not good enough”) create remediation cycles that go in circles.
  • Confirm quickly. ODS pricing reflects the timeline agreed at scoping. Late confirmation can delay team assembly and compress the delivery window, which increases risk.
Last modified on April 15, 2026