Sprints

A Sprint is a time-boxed Project planning and delivery cycle. Sprints move through future, active, and done states and show progress across their committed Work Items.

Plan a Sprint

1. Create a future Sprint with a name and dates.
2. Add Work Items from the Work Items view — the Unscheduled filter is a good starting point.
3. Reorder the Sprint list to make priority clear.
4. Start the Sprint when the team is ready to commit.

Items are appended when assigned. Removing a Work Item’s Sprint assignment (returning it to unscheduled work) clears its Sprint order.

Sprint order is its own order

Sprint ordering is separate from Board status ordering. A Board move can change a Work Item’s status without changing its priority in a Sprint, and Sprint reordering does not move a card between Board columns.

Reordering is conflict-safe: if another teammate changes the Sprint before your update is saved, Hamstik asks you to reload rather than silently overwriting their order.

Plan capacity

Open Team capacity on a Sprint to plan who carries how much work. Points are the primary planning unit; every aggregate sums each Sprint Work Item’s own estimate once and never adds rolled-up parent totals.

Per member the ledger shows:

• Capacity — persisted planning points for the Sprint (admin-managed).
• Committed — manual commitment points, preserved separately and never overwritten from assigned work.
• Assigned — computed from the Work Items currently assigned to the member.
• Remaining — open-item points; Done work contributes zero and unfinished work keeps its full estimate.
• Variance — assigned minus capacity. Above capacity is Overloaded; equality is At capacity. A missing capacity entry makes the status Incomplete rather than falsely green.
• Unestimated — how many assigned items lack an estimate.

Unassigned work has its own bucket with no invented capacity. Warnings are informational and never block assignment or transition.

Optional minute availability

Admins can declare per-member minute availability for a Sprint: an IANA time zone, explicit opt-in, per-weekday minutes (0–1,440), and dated overrides (0–1,440) for leave, holidays, or part-time days. Availability is declared, never inferred — members without a row have unknown minute capacity, and no hours are derived from points. Remaining availability is scheduled from the day after the as-of local day (tomorrow-forward); a future Sprint begins at its start date, and DST never alters declared day minutes.

The time view shows planned minutes (original estimates), remaining minutes (unfinished items), and actual minutes (authorized worklogs credited to the recorded worklog author, never the assignee). Overload in the time view means remaining minutes exceed remaining scheduled available minutes.

Forecast and risk

The points forecast uses the arithmetic mean of completed-points-per-working-day rates across the last three completed Sprints in the Project (rate = (P1/D1 + P2/D2 + P3/D3)/3, using the closed-Sprint metric snapshot) and predicts the remaining working days for open points. Fewer than three eligible Sprints, or a zero rate, shows insufficient history.

The time projection allocates known remaining minutes to each member’s future configured working-day minutes and reports the latest individual finish date, searching at most 365 days ahead. Missing estimates, unassigned effort, missing availability, or no future capacity make the projection incomplete. A complete projected finish beyond the Sprint end is derived at risk; this is report metadata, separate from the manual Work Item effort-risk signal (none, blocked, at_risk) that Work Item writers can set through the UI and API.

Delivery Team roll-ups (where teams exist) sum each unique member once across teams; individual team rows may overlap and say so. Team planning requires Delivery Teams (see Teams).

Every view states its assumptions, the as-of moment, and unknown counts. Sprint start freezes an immutable planning baseline (commitments, capacity, and estimates); a Sprint that was already active when planning shipped records a clearly labeled partial baseline on first read. Closed-Sprint baselines are immutable, and moving an item never rewrites recorded attribution.

The aggregate planning view is readable by every authorized Project reader through GET /api/v1/organizations/{organizationSlug}/projects/{projectKey}/sprints/{sprintId}/capacity-planning; availability management is admin-only (GET/PUT .../sprints/{sprintId}/availability, scope project:read / project:write).

Complete a Sprint

Completing a Sprint requires its Work Items to satisfy the current completion rules. If work remains, review the completion target and move unfinished items deliberately before trying again.

Only an empty future Sprint that has never held Work Items or reporting history can be deleted. Once a Sprint is active, completed, committed, or referenced by membership history, Hamstik retains it so delivery reports remain reproducible.

Read a Sprint report

Open Reports → Sprint report from a Project to review a selected Sprint. Hamstik selects the most recently completed Sprint by default. If the Project has no completed Sprint, it selects the active Sprint and then the first future Sprint. The selected Sprint is stored in the sprint URL parameter, so a report link can be reloaded, shared, or revisited with browser navigation.

The report uses the immutable sprint_commitment baseline for commitment at the start. “Completed” means that a Work Item reached done while its commitment episode was assigned to that Sprint. Scope additions and removals are attributed to the recorded commitment and removal times. A completed Sprint’s carryover is the Work Items that were not done at completion; each entry identifies whether completion moved it to unscheduled work or another Sprint. Active Sprint work is shown as remaining or at risk, not as completed-Sprint carryover. Future Sprints show planned scope only.

Completion percentages state their denominator: final scope includes additions that remained in scope at the reporting boundary, while original commitment includes only items committed at Sprint start. Point percentages use recorded Sprint commitment points; item percentages are available when a point denominator is zero. A missing baseline or incomplete status history makes the reconstructed burndown unavailable rather than inventing historical values.

The report includes an accessible data table for every burndown value and status distribution, real lists for scope changes and carryover, links to the matching Work Items, and CSV, SVG, and PNG exports. SVG and PNG exports include explicit light and dark theme colors.

See Boards for status-based flow and Work Items for item fields and activity.