Cycles and sprint planning

You will learn what cycles are, how cycle states work, and how Tixio tracks sprint scope from planning through close.

A cycle is a time-boxed planning window for a project. Many teams use cycles as sprints. A cycle groups the issues the team intends to work on during a date range and gives Tixio enough structure to report on capacity, scope changes, carry-over, burndown, burnup, and velocity.

For step-by-step instructions, read Plan and run a sprint.

Cycle states

Cycles move through three states:

State	Where it appears	What it means
Planned	Upcoming	The sprint exists, but commitment has not started yet. You can edit its name, description, and dates.
Active	Active	The sprint has started. Tixio treats current scope as live sprint work and tracks scope changes.
Closed	Closed	The sprint is finished. Its report and carry-over outcome are historical records.

The Cycles page groups cycles as Active, Upcoming, and Closed.

Cycle fields

A cycle has:

Name, such as Sprint 7.
Description, optional context for goals or planning notes.
Starts date.
Ends date.
A project-scoped cycle number.

Dates can be edited while a cycle is planned. After the sprint starts, Tixio freezes the date window so analytics stay honest.

Cycle scope

Cycle scope is the set of issues assigned to the cycle. You can put issues into a cycle when creating or editing an issue, from table or bulk-edit flows, saved views, or automation/AI workflows that can move issues into a cycle.

Tixio shows cycle scope on the cycle detail page under Issues in scope. Large cycles load issues progressively and show a loaded-so-far hint while more issues are available.

Capacity and completion

Cycle cards and cycle detail use a capacity bar. The bar summarizes completion using estimates when the cycle has estimates, or issue counts when estimates are not available.

For active cycles, the bar can also show days remaining, ends today, or overdue. Closed cycles render as complete visually, but the numbers still tell whether work was completed or carried over.

Commitment snapshot

When you start a cycle, Tixio records a commitment snapshot. That snapshot is the baseline for sprint reporting.

The snapshot lets Tixio answer:

What was committed at sprint start?
What completed during the sprint?
What was added after start?
What was removed after start?
Which estimates changed after start?

Without a start snapshot, old cycles can still show a capacity summary, but the Sprint Report cannot reconstruct every commitment and scope-change section.

Scope changes

Scope changes are normal, but they should be visible.

Tixio tracks work added to the sprint after start, work removed from the sprint, and estimate changes. Use that information in sprint review and retrospectives to distinguish delivery problems from changing scope.

Carry-over

When closing a cycle, Tixio asks what to do with incomplete issues:

Move to backlog: safe default. The team decides later whether to pull each issue into another cycle.
Move to next planned cycle: useful when unfinished work should continue immediately and a planned cycle exists.
Keep on this cycle: keeps incomplete issues attached as historical scope. Use sparingly because it can make active planning less clear.

The close outcome is visible on the closed cycle and Sprint Report.

Cycle filters

Issue surfaces include a Cycle filter. Useful cycle filters include:

Current or active cycle.
Past cycles.
No cycle.
A specific planned, active, or closed cycle.

Use No cycle to find backlog work that has not been planned. Use current or active cycle filters for standup and sprint review. Use past cycle filters when you need historical context.

Reopening cycles

Closed cycles can be reopened. Reopen only when the cycle was closed by mistake or the team intentionally needs to continue sprint work. Reopening should be rare; most unfinished work should move through the selected carry-over policy.