Project Sprints

Backlog, sprints and delivery reports

Open a project, then Backlog and sprints. Plan and rank work, run parallel sprints, and retain a historical record when a sprint closes.

A normal sprint

Create sprint: name, goal and optional start/end times. Times are explicitly labelled UTC. Administrators manage the lifecycle; project members assign and rank work.
Select backlog items, choose a sprint and Move selected. Drag a row before another or use Move up. Saving restores the originating sprint and page, with a confirmation.
Choose the sprint and Start sprint. Set both dates first. The start action freezes the initial count, points and estimated minutes.
Use Open sprint board to work on that sprint using the existing board. Sprint report and charts shows daily progress and scope changes.
Complete sprint: unfinished work returns to the backlog or moves to another planned/active sprint. Finished work leaves current planning. Completed history cannot be edited or deleted.

stateDiagram-v2
    [*] --> Planned
    Planned --> Active: Start and capture baseline
    Active --> Closed: Freeze outcome and carry unfinished work
    Planned --> [*]: Delete and return work to backlog
    Closed --> [*]: Retained historical record

Multiple sprints may be active independently. Browse all sprints and history provides paged access to every sprint, including those outside the current selector or recent velocity table.

Trustworthy numbers

Stories, tasks and bugs carry sprint membership. Subtasks inherit their current parent's sprint; their estimates are not added again. Epics remain separate planning containers.
Count, story points, estimated minutes and remaining minutes are separate units. Missing estimates are disclosed rather than described as completed effort.
Status and estimate changes, work logs, additions and removals record event snapshots in the same transaction. Reporting reads historical snapshots, not today's mutable fields.
Burndown shows remaining work and an ideal guideline; burnup shows scope versus completed work. Remaining-minute tracking has a burndown, without a misleading “completed remaining minutes” burnup.
Work completed before entering the active sprint is shown separately and excluded from delivered velocity. Reopened work subsequently completed during the sprint can be credited.
A finished parent with unfinished subtasks blocks completion; finish its subtasks or reopen the parent to carry it forward.
Closed baselines and outcomes remain frozen after later item edits. Moves/deletions record scope removal; historical keys, titles and estimates survive. Historical API responses never expand a moved item from a private destination project.

Tables provide exact, accessible values alongside charts. Backlog, historical work breakdown and sprint history are paged at 50 rows. Tables scroll by keyboard on small screens; chart labels remain readable outside the SVG. A single day's activity is labelled as such rather than presented as a trend.

Permissions and limits

Private projects remain private; tenant boundaries and current project access apply to every web/API read. Lifecycle changes require project administration, and assignments require project edit access. All mutation requests recheck project state and authorization after taking the project lock. A stale item that moved projects returns conflict and must be reloaded.

One work item can have only one current sprint membership, enforced by a PostgreSQL partial unique index. Historical memberships remain separate. Bulk assignments are transactional: one invalid item rolls back the request. Web mutations require CSRF protection; API calls require the existing project scopes. API creation requires an idempotency key.

A sprint has at most 5,000 current top-level items. Planned duration is at most 366 days. Charts support 366 days of actual activity and 50,000 events; larger histories remain accessible through paginated events. The current selector shows up to 100 planned/active sprints; the paged history view covers the rest. Velocity shows the latest ten completed sprints. These are explicit bounds, not unlimited-capacity claims.

Queries

project = WEB AND sprint IN openSprints()
sprint IN futureSprints() AND assignee = currentUser()
sprint IN closedSprints() ORDER BY updated DESC
sprint = 42
sprint = "Portal delivery"
sprint IS EMPTY

Sprint names need not be unique; use an ID when one exact sprint is intended. openSprints(), closedSprints() and futureSprints() take no arguments and support IN/NOT IN. Membership queries include nested subtasks through the current parent hierarchy. Completed membership is retained; membership removed before closure does not become a completed-sprint assignment. Existing board/list filters accept a same-project sprint ID.

REST contract

Every path below is under /api/v1/projects/{key}. Reads require projects:read, writes projects:write, plus the acting user's project permissions. JSON responses follow existing data/meta conventions. Timestamps normalize to UTC; absent offsets mean UTC.

Method/path	Behavior
`GET /sprints`	List, with optional state `planned/active/closed`, limit 1–200 and offset 0–1,000,000.
`POST /sprints`	Administrator + `Idempotency-Key`; name, goal, optional paired start_at/end_at ISO timestamps. Safe creation replay.
`GET/PATCH/DELETE /sprints/{id}`	Read; edit name/goal/dates while planned or active; delete only while planned. Unknown fields rejected.
`POST /sprints/{id}/start`	Administrator, empty JSON object; freeze baseline and start.
`POST /sprints/{id}/complete`	Administrator; optional integer destination_id or null for backlog. Atomic carry-over and frozen outcome.
`PUT /sprint-items`	item_keys (1–100), sprint_id integer/null, optional before_key for one item. Assignment is repeat-safe; ranking stays in the same backlog/sprint.
`GET /sprints/{id}/items`	Paged current membership, or historical membership for a closed sprint. Live item expansion only for current, same-project records.
`GET /sprints/{id}/events`	Paged immutable scope/state/lifecycle snapshots.
`GET /sprints/{id}/report`	unit count/points/estimate/remaining; baseline, frozen outcome, daily series, bounded work breakdown and latest 100 events.
`GET /velocity`	Last ten completed baselines/outcomes, including delivered_count/delivered_points/delivered_estimate.

The API exposes backend capabilities for native clients. New native iOS sprint screens are not part of this implementation.

Programme status

This implements the sprint/backlog lifecycle and core sprint reports in B-451/B-452, plus sprint functions in B-450. Those phases remain in progress: multiple/cross-project boards, configurable columns, advanced card/swimlane/estimation/calendar options, epic/version backlog panels and the other report families remain open. It does not complete B-450–B-459, operational Premium controls or JSM Premium parity.

Implementation plan · Premium assessment · Search syntax

Reference behavior

The supported scope is recorded above; this is not a claim of complete Jira compatibility. See Atlassian's sprint burndown report, parallel sprints, and sprint completion for comparison. ServiceOps additionally allows transactional carry-over directly to another active sprint.

Validation, deployment and interface previews

ServiceOps repository · Releases · Documentation home