Sprints
Plan a sprint with its dates, goal and capacity, pull its scope from the backlog, put it to the team for the commitment that starts it, follow it while it runs, close it with its velocity and carry the unfinished work on.
By the end of this page you will know how a sprint is planned and dated, how its scope is pulled from the backlog, how the team's commitment starts it and what that approval pins, what the page shows while it runs, how it is closed with its velocity and where the unfinished work goes, and how a sprint is cancelled or deleted.
A sprint is a dated run of work the team commits to. It is numbered within the project (Sprint 1, Sprint 2), given a goal and a capacity in points and hours, and filled with work items from the backlog as its scope. A planned sprint is put to the team through the Sprint commitment approval; when that carries, the sprint is active, stamped with the points it committed to, and the one running sprint of the project. Closing it records the points of the items done as its velocity and carries the unfinished items to the backlog or the next planned sprint. Every save of a sprint's name, goal, dates, capacity or retrospective keeps the version before it. Sprints are the team's: a client guest never opens the page.
Before you begin
| To | You need |
|---|---|
| See the sprints and open one | sprint:view-any and sprint:view; a viewer, an analyst, a tester and a release manager read them |
| Plan a sprint and change it | sprint:create, sprint:update; the project manager and the developers by default |
| Plan the scope | work-item:update |
| Put a sprint to the team | sprint:start |
| Commit | To be named by the project's Sprint commitment policy; the project manager and developer roles by default, any one of them |
| Close a sprint | sprint:close |
| Cancel a sprint | sprint:update |
| Delete a planned or cancelled sprint | sprint:delete |
The project's sprint length under project settings dates a new sprint; two weeks unless the project says otherwise.
Open the page
Sprints in the project's sidebar opens the page; the badge on the entry counts the sprints still ahead or running. When a sprint is running, a card above the list shows it first: its name and number, its dates and the days left, how many items are done of its scope, the points done against the points planned, what it committed to and its capacity, with a bar for the progress and the buttons to view it, plan its scope and close it.
The list shows each sprint's name and number with the first line of its goal, its dates with the days left while it is open, its status, how many items it holds, its points (what it committed to, and what it finished once closed) and its capacity. Sort by number, dates or status; narrow the list by status or search by name; Clear Filters drops every filter.
An empty project reads No Sprints Yet and, to someone who may plan: Plan the first one with the button above: name it, date it, pull its scope from the backlog, and put it to the team; their commitment starts it.
Plan a sprint
Press New Sprint. The editor asks for a Name (Sprint 3), a Goal in a sentence or two, the dates (Starts on is today and Ends on the start plus the project's sprint length, both changeable), and the capacity: Capacity in points, how many story points the team expects to finish, and Capacity in hours, how many hours it has after leave and other work. Press Plan Sprint. The sprint is written as Planned, numbered within the project, and the toast reads Sprint planned.
A planned or running sprint changes through Edit Sprint in the row menu or Edit in the flyout: the name, the goal, the dates, the capacity and, while it runs, the Retrospective. Save Changes writes a version. A sprint with the team for its commitment does not change until they answer, and a completed or cancelled one never does.
Plan the scope
Plan Scope in the row menu, the flyout or the running sprint's card opens the planner on the open backlog items not yet in a sprint, each with its reference, title, kind, status, points and assignee. Tick the items and press Add to Sprint; an item joins at the points it carries today. The flyout's Scope table lists what the sprint holds, and the cross on a row sends that item back to the backlog. An item that is done or cancelled does not join; a sprint that is with the team, completed or cancelled takes no more items and gives none back.
The backlog plans from its own side too: the Sprint submenu on an item's row and the Sprint field in its editor move one item into a planned or running sprint or back to the backlog, and the backlog's sprint filter shows one sprint's items or the items in no sprint.
One sprint at a time
A project has at most one running sprint. A planned sprint cannot be put to the team while another runs; close or cancel the running one first. Items may wait in several planned sprints at once.
Put it to the team and start it
Open a planned sprint's flyout. Once it holds at least one item and has both dates, the Approval bar offers Submit for review: write a few lines for the team under Summary and confirm. The sprint moves to Awaiting commitment, the approvers of the project's Sprint commitment policy are told (the project manager and the developers by default, any one of them carrying it, with a day to answer), and the scope holds until they do.
What the commitment does when it carries:
- The sprint becomes Active at version 1, stamped with when it started, who put it to the team and the points its scope held, which stay as Committed however the scope moves afterwards.
- The running sprint's card appears above the list, and the backlog shows the sprint on each of its items.
sprint.startedgoes out besidesprint.status_changed, with the approval that carried it, the points committed to and the number of items.
A rejection returns the sprint to Planned with the approver's reason on the request; a request for changes holds it until you resubmit. A project whose commitment gate is switched off starts the sprint at once, as an approval that carried by itself.
Follow it while it runs
Open a running sprint for its flyout: the dates and the days left, the capacity, the points done against the points planned with what was committed, when it started and by whom, the goal, and the Scope table with each item's status, points and assignee. Items still join and leave a running sprint; the committed points keep the record of what the team took on. The sprint's own Versions and Activity sit below. The board and the burndown join this flyout when they land.
Close it
Close Sprint in the row menu, the flyout or the running sprint's card opens the close dialog with the count of items done, the points done that become the velocity, and the count of unfinished items. Choose where the unfinished items go under Carry the unfinished items to: a planned sprint of the project, or Back to the backlog when left empty. Write the Retrospective (or leave it empty to keep what was written during the sprint) and press Close Sprint.
The sprint becomes Completed: its completed points and velocity are the points of the
items done, when it closed and who closed it are stamped, the unfinished items move where you chose,
and sprint.closed goes out beside sprint.status_changed with the velocity, how many items were
carried and where. A completed sprint is the record of what the team did: it is never edited,
rendered or deleted.
Cancel or delete a sprint
A planned or running sprint that will not happen is cancelled from Move to → Cancelled in the row menu or the flyout; its items go back to the backlog and the sprint stays readable. The moves through Awaiting commitment, Active and Completed belong to the commitment and the close, and the menu does not offer them.
Delete Sprint removes a planned or cancelled sprint with its versions and activity; its items go back to the backlog. A sprint the team committed to, running or completed is refused: cancel or close it instead.
All the fields
What happens next
- Planning a sprint emits
sprint.created; every change to its words, dates or capacitysprint.updatedwith what changed; planning the scopesprint.scope_changedwith the references that joined and left. - The commitment emits
approval.requested, the verdicts andsprint.status_changedon every move; the start addssprint.startedwith the approval, the points committed to and the item count. - Closing emits
sprint.status_changedandsprint.closedwith the velocity and what was carried; cancelling emitssprint.status_changed; deleting emitssprint.deleted; putting an earlier version back emitssprint.restored. - An item planned into a sprint from the backlog announces itself as
work_item.updatedwith the sprint that changed, and shows the sprint on its row and in its flyout. - The sidebar badge counts the open sprints; the board, the burndown and the time logs read the running sprint as those modules land.
Heimdall on this page
Heimdall reads sprints and plans into them when asked: "What is in the running sprint and how far along is it?" reads the scope and the points done against the commitment; "Plan the password stories into Sprint 3" moves the items through their own sprint field; "What velocity did we reach in the last sprints?" reads the closed ones. Heimdall never plans, starts, closes or cancels a sprint itself; those stay with the team.
From the API and MCP
Sprints API
A project's sprints, one with its items, plan and change a sprint, plan the scope, cancel, close, delete, the versions, and the submit door for the commitment.
list_sprints and get_sprint
An agent reads the running sprint and its scope before it picks up work, and the closed ones for their velocity.
update_work_item
Plan an item into a sprint, or send it back to the backlog, through the item's own sprint field.
sprint.* events
Created, updated, status changed, started, closed, scope changed, restored and deleted.
Permissions
| Action | Permission |
|---|---|
| See the sprints and open one | sprint:view-any, sprint:view; never a client guest |
| Plan a sprint, change it, cancel it | sprint:create, sprint:update |
| Plan the scope | work-item:update |
| Put a sprint to the team | sprint:start, as staff |
| Commit | Named by the Sprint commitment policy; approval:decide over the API |
| Close a sprint | sprint:close |
| Delete a planned or cancelled sprint | sprint:delete |
| Read and restore the sprint's own versions | sprint:view, sprint:update; on a planned or running sprint |
Frequently asked
Can two sprints run at once? No. A sprint cannot be put to the team while another runs. Teams that work in parallel streams run one sprint and tell the streams apart with labels or epics on the items.
The scope changed after the team committed. Which number counts? Both are kept. Committed is the points the scope held when the commitment carried, and stays as the record of what the team took on; the points planned and done follow the scope as it stands, so the gap between them is the scope change.
An item was carried into the next sprint. Does it keep its status? Yes. Carrying over changes the item's sprint and nothing else; it keeps its status, its assignee and its points, and the closed sprint keeps the items that were done.
We do not vote on commitments; can the sprint just start? Switch the Sprint commitment gate off under the project's approval policies, or name a single approver. With the gate off, submitting starts the sprint at once; the submission is still what stamps the committed points.
Related
- Backlog: the items a sprint takes on, and the sprint field and filter there.
- Approvals: the Sprint commitment policy, the inbox and the verdicts.
- Project settings: the sprint length that dates a new sprint.
- Revisions and versions: every save of a sprint, compared and put back.
How is this guide?
Last updated on
Board
The Board page of a project: the running sprint's work in a column per status, dragged along its lifecycle and into its place in the order, with the limits each column keeps, swimlanes by epic, person or kind, and the quick filters.
Documents
The documents a project generates from the record its team wrote once: the business requirements document the client signs and the software requirements specification the team builds against, each rendered, reviewed, approved and shared from one page.