# Sprints and milestones (https://docs.vitrinka.ai/pm/sprints) ## Sprints [#sprints] A sprint groups work around a named outcome, a goal and declared product, component or task coverage. Dates are optional and stay unset when omitted. A task has at most one owning sprint. Names are unique within a project; you can rename a sprint or change its dates. Sprints remain in history and cannot be deleted. The project's [Overview](/pm/brief) leads with its sprints on a timeline: pick a sprint's band and the page below shows its cockpit and its tasks, where you start or complete it and add work straight into it (an older Sprints-hub link lands there too, its sprint kept). The same click opens the sprint's card on the right panel — the one place a sprint is edited: name, goal, start and end date (each set or cleared on its own) and covered components, with its progress beside them. Plan › Backlog lists the open work outside any sprint. Move a task into the sprint with **Move to sprint** on its row, or select several tasks and use the bulk bar. * **Start** a sprint on its own or alongside other active sprints. Starting one never silently completes another. * **Complete** through a reviewed preview: select the unfinished tasks to carry and explicitly choose a destination sprint or backlog. Apply moves only that selection, preserving each task's status and membership history. Unselected and completed work stays in the original sprint. * If the scope changes after preview, refresh and review it again. Repeating an apply with the same request ID is safe. In the browser, **New sprint** leads the timeline's toolbar and opens an empty card with **Create**; **Start sprint** or **Complete sprint** stands beside the picked sprint's title and in its card's top bar. Completion asks you to select unfinished tasks and a destination, then review the preview before applying it. From a terminal: ```bash vitrinka sprint create "Checkout delivery" --goal "Ship reliable checkout" --coverage component:checkout vitrinka sprint start 13 vitrinka sprint complete 12 --into 13 --task 41,42 > carry-preview.json vitrinka sprint complete 12 --apply carry-preview.json --request-id checkout-carry-1 ``` Review the preview file before the second command. Use `--into 0` for backlog; omitting `--task` selects no tasks. There is no automatic next sprint based on dates. ## Session scope and routing [#session] Before brainstorming creates feature work, choose a sprint or explicitly choose **No sprint**. A session begins as `unknown`; `none` is an affirmative choice, not the absence of one. The binding is stored per project and session, with a version that prevents overwriting a newer choice. ```bash vitrinka sprint binding get vitrinka sprint binding set --sprint 13 --version 0 vitrinka sprint binding set --none --version 1 ``` Use the version returned by the preceding read; `0` is only for a previously unknown binding. Children and necessary follow-ups inherit the approved work's scope. A verified bug routes to the one active sprint whose declared coverage matches. Several matches require a choice; unverified bugs, uncovered bugs and enhancements enter [Intake](/pm/intake). ## Milestones [#milestones] A milestone marks a date such as a release or demo. Tasks can reference one milestone. The timeline displays milestone markers, **+ Filter** narrows any task display to one milestone, and a todo can wait for it to be reached (`vitrinka me todo milestone reach`) — see [reminders and milestones](/use/day#reminders). Milestones can be renamed and rescheduled; they cannot be deleted. ## Where they show [#where] Task filters support `sprint` and `milestone`, and saved views keep that selection. Agents use `create`, `update` and `list` with `kind: "sprint"` or `kind: "milestone"`. The [release flow](/pm/release) separately collects merged work into the next release page. The [Overview](/pm/brief) shows the picked sprint's work and readiness; [Product history](/pm/history) retains its evidence.