¶Cycles

A fixed window of time that arrives on a cadence. Cycles, in the sidebar.

¶Why cycles and not sprints

A sprint is a container for a ceremony. Somebody names it, fills it, starts it, and closes it — and every one of those verbs is a step that can be skipped, which is why half the teams using sprint tools have a Sprint 47 that ran for nine weeks.

Two things about Félagi make that shape wrong here.

Agents do not attend planning meetings. They work continuously, which is the whole point of them. A ceremony container is a human artefact, and half this workforce is not.

Capacity here has always been a rate, not a rota — weekly hours on a membership and on an agent, from which the Gantt computes what actually fits. A cycle is a window over that same timeline, not a separate plan competing with it.

So: pick a length, and the windows exist from then on. There is nothing to open and nothing to close.

¶Turning it on

Choose one to four weeks. Félagi generates the current window and the next few to plan into, and felagi:cycles keeps them coming every night.

The first window starts at the cadence boundary on or before today, not today. A first cycle four days long teaches a team nothing when compared with the next one.

Numbered, not named. Cycle 12 is what somebody says out loud anyway, and a name is one more thing to invent every fortnight.

¶What is unfinished moves on

When a window's time is up, everything in it that is not done or cancelled moves into the current window — and Félagi counts how many times that has happened to each issue.

That count is the most useful number a planning tool can produce, and it is the one most of them hide. "We have carried this for four cycles" cannot be reconstructed afterwards from anything else, so it is a column on the cycle page and a line on the issue.

Finished work stays where it was finished. Its history is the point.

The windows close oldest first. Out of order, an issue carried from cycle 10 could land in 11 and be moved again by the same run — counted twice for one missed deadline.

¶Does it fit?

Planned   6d      across 5 issues
Capacity  40d     20d people · 20d machines

This is the comparison no other tracker can make, because the machines are in the capacity number. An agent's weekly hours count exactly as a person's do, so a window's capacity is the whole workforce rather than the human half of it.

Three things about how it is counted:

Issues without an estimate are counted separately, never as zero. Treating them as zero makes an under-planned cycle look comfortable, which is the opposite of what somebody needs to know.

Nothing is refused for not fitting. A plan that cannot be over-committed is a plan nobody believes. Over-commitment is reported, along with what it means: this is what will be carried into the next window.

Working days, not calendar days. A fortnight from a Monday is ten days, not fourteen.

¶The windows before this one

One cycle's numbers mean nothing alone. The last few closed windows are shown beside the current one, because "you finished 14, 11 and 16" is what makes the fourth one a forecast rather than a hope.

¶What a cycle does not do

It does not touch dates. A cycle is where work is planned; the Gantt works out what actually fits from capacity and dependencies. A window that rewrote start dates would be arguing with the thing that computes them.

It does not delete anything. Turning cycles off leaves every window and everything in them — switching off a cadence should not unplan a quarter of work. Deleting a window leaves its issues, unplanned.

It does not close a window twice, and re-running the command is safe. That idempotence is the property that lets cycles be generated at all: a workspace nobody looked at for a month catches up rather than getting a gap.

¶Not there yet

• No burndown. Progress is a bar and a count; there is no chart of remaining work over time.
• No velocity forecast. The last few cycles are shown; nothing extrapolates from them.
• No per-project cycles. One cadence per workspace, because capacity and membership live there.
• No cycle in the import. A window in Jira is a sprint somebody opened on a date that is not in the export, and Félagi's are generated on a cadence — there is nothing to map a sprint name onto without inventing the dates.
• Nothing writes a cycle over the API. It is readable on an issue and filterable with ?cycle=, but setting one is done in the interface.
• Nothing schedules work into a cycle for you. Capacity is compared against what somebody planned; it does not plan.