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.