Sprints — ProxifAI Docs

A sprint is a time-boxed batch of issues belonging to a single team. ProxifAI supports the basics — start/end dates, a goal, an issue list — without forcing scrum ceremony on you. Source: type Sprint struct in models.go.

Anatomy of a sprint

Field	Type	Notes
`name`	string	”Sprint 12”, “Q2 W3”, or whatever convention you prefer
`goal`	nullable	One-line outcome the team’s driving toward
`status`	enum	`planning` · `active` · `complete` (only three)
`startDate`, `endDate`	nullable dates
`teamId`	required	Sprints belong to exactly one team — there are no org-wide sprints
`tasks`	computed	Issues with `sprintId` set to this sprint

Status

Three statuses, defined as SprintStatus:

Status	Meaning
`planning`	Sprint is being scoped — issues can be added/removed freely
`active`	Sprint is in flight — at most one per team at any time
`complete`	Ended — read-only except for moving leftover issues

Activate a planning sprint when ready; complete it when the end date passes (the UI prompts you).

One active sprint per team is enforced — activating a new sprint while one is already active will fail. To run parallel workstreams, create separate teams or use labels within a single sprint.

Creating a sprint

From the UI

Plan → Sprints → New (or per-team Sprints tab). Name + start + end dates. Goal is optional but useful — it prints on every standup view.

From the CLI

pfai sprint create "Sprint 12" \
  --team backend \
  --start 2026-05-12 --end 2026-05-26 \
  --goal "Ship OIDC login GA"

Adding issues

Three paths, all writing the same sprintId field on the issue:

Drag-and-drop from the backlog onto the sprint board
Set the sprint property on individual issues (Sprint: dropdown) or in batch from the issue list
CLI: pfai sprint add-task sprint_42 BACK-100 BACK-101

Issues can be removed the same way (pfai sprint remove-task or just unset the field).

Activating and completing

pfai sprint update sprint_42 --status active     # only one active per team
pfai sprint update sprint_42 --status complete   # close it out

When you complete a sprint with open issues remaining, the UI offers per-issue:

Move to next planning sprint (if one exists)
Send back to backlog
Leave as-is (sprint stays as the issue’s sprintId, but the sprint is complete)

Nothing is silently dropped.

Progress

While a sprint is active, the detail page shows:

Completion bar — done / total non-cancelled
Issue breakdown by status — counts across all six issue statuses (incl. in_review)
Burndown — daily snapshot of remaining (non-done) issues vs. an ideal-line projection
Daily delta — issues added or removed each day, surfacing scope creep

After completion, pfai sprint stats sprint_42 (or the UI’s Stats tab) gives:

Velocity — issues (or estimate-summed points) completed
Carry-over — count moved to the next sprint
Cycle time — average in_progress → done duration
Scope change — issues added after start

Team scoping

Sprints belong to exactly one team. In multi-team orgs:

Each team maintains its own cadence
The sprint board shows only issues assigned to team members
Project dashboards aggregate sprint data across teams that contribute issues to the project

A single project can therefore have several concurrent sprints — one per contributing team.

REST endpoints

Method · Path	Purpose
`GET /api/v1/sprints?team=&status=`	List
`POST /api/v1/sprints`	Create
`GET /api/v1/sprints/{id}`	Read (with embedded `tasks[]`)
`PATCH /api/v1/sprints/{id}`	Update name/goal/status/dates
`DELETE /api/v1/sprints/{id}`	Soft-delete
`POST /api/v1/sprints/{id}/tasks`	Add issues
`DELETE /api/v1/sprints/{id}/tasks/{issueId}`	Remove an issue
`GET /api/v1/sprints/{id}/stats`	Velocity, carry-over, cycle time, scope change