Sprints¶
A sprint is a time-boxed iteration: a fixed window in which the team commits to a set of issues and a goal. Where versions plan toward a release, sprints plan the next week or two of work. You plan a sprint, start it, and complete it.
What a sprint holds¶
| Field | What it holds |
|---|---|
| Name | The sprint label, e.g. "Sprint 14" |
| Goal | A one-line statement of what the sprint aims to achieve |
| Status | Planned, active, or completed |
| Start date / End date | The window the sprint runs for |
One active sprint per project
A project can have only one active sprint at a time. Plan as many sprints ahead as you like, but you start them one after another.
The sprint lifecycle¶
- Plan. Create the sprint, set its goal and dates, and pull issues into it from the backlog while its status is planned.
- Start. When the window opens, start the sprint. It becomes the project's one active sprint, and its issues show up on the sprint board.
- Complete. At the end of the window, complete the sprint. Completing it snapshots the team's velocity — a record of how much work was finished — so you have a baseline for planning the next one. Issues that aren't done move to the backlog, or to another planned or active sprint of the same project if you pick one.
A completed sprint is closed to new issues¶
Once a sprint is completed, no issue can be added to it: the sprint pickers no longer offer it, and the REST API and MCP refuse it. An issue that is already in a completed sprint keeps showing it, and you can still take the issue out (clear its sprint, or move it to an open sprint). That doesn't change the sprint's velocity, which was recorded when it was completed.
The lifecycle in issue history¶
Starting and completing a sprint shows on each affected issue's Activity tab, credited to the person who did it: "Sprint «name» started" on every issue in the sprint, "Sprint «name» completed" on the issues that stayed, and a normal sprint change on the issues that moved out. These lines don't send notifications.
What counts as done¶
Specivo decides whether an issue is done by its status's category (done or closed), never by the status's name. The sprint list, the board's progress line, the burndown, the analytics page and the velocity snapshot all use the same rule. If your team renames Resolved to Shipped, nothing changes, and an in-progress status that happens to be called "Resolved" is not counted as done.
Velocity and private issues¶
The velocity of a completed sprint, and the counts on the sprint pages, cover only the issues you may see. Two people reading the same completed sprint can therefore see different numbers when some of its issues are private or hidden by their role. The REST API and MCP return the counts, never the ids of the issues behind them.
The backlog¶
The backlog is the pool of issues that aren't yet committed to a sprint. This is where you plan: review what's waiting, decide what fits the next iteration, and assign issues to a sprint. An issue's sprint field is the link — set it (from the backlog or the issue itself) to pull the issue in.
The sprint board¶
The sprint board shows the active sprint's issues as cards in columns by status — New, In Progress, Resolved, and so on — so the team can see the state of the iteration and move work along. The columns follow the status categories (backlog, active, done), the same ones that drive the issue board.
Use the board during the sprint for the day-to-day flow, and the roadmap when you need the longer view across releases.