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.

Starting work plans it

Move an issue into a started status — In progress, In review, whatever this workspace calls them — and if it is in no cycle, it joins the current one.

This is the gap every cycle tool leaves. Somebody picks up the next thing on a Tuesday because it is the next thing, and the window they are working in has no record of it; at the end of the fortnight the burndown is wrong, the capacity figure was answering a question about a different set of issues, and the carry count is short by everything that was done without being planned.

Four things it deliberately does not do:

It does not overrule a plan somebody made. An issue already in a window stays in that window, even a future one. Starting next month's work early is not a reason to silently move it out of next month.

It never plans standing work. A support rota has no window; it is time that recurs, and a cycle empties it out again when the window closes.

It only plans into an open window that covers today. No cadence, no window today, or a window closed early — nothing happens, rather than the work landing somewhere arbitrary.

It happens wherever the status changed — the board's drag, the bulk bar, the issue page, the API, a reply to an email, an agent finishing a run. A rule that lived in the board would be a rule about the board.

It is written to the issue's history as planned into cycle #12, because a change to somebody's plan that nobody asked for should be traceable to the thing that caused it.

Carried three times is a decision, not a delay

Past three windows the carry count stops describing lateness and starts describing a decision nobody has taken: the work is either not wanted or not next, and every fortnight it is carried again the plan says it is both. So the cycle page names them, and says what the two honest moves are.

2 issues have been carried 3 times or more. They are not going to happen by being carried again. Close them, or make one of them next.

Three, because that is where the carry column already turns red. Finished work that was carried a lot is history, not a decision — it is not listed.

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.

Four things about how it is counted:

Leave comes out of it. Absence recorded on a timesheet is time that does not exist, so a window with a week of somebody's holiday in it holds a week less — and the card says so rather than merely being lower than expected. See Absence.

Standing work does not. A support rota is time that exists and is committed, which is a different thing from time nobody is there for: the capacity figure is what the window holds, and the Gantt's projection is where committed time is subtracted.

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.

What the plan has historically cost

Beside the capacity check: the plan multiplied by how this workspace's estimates have actually behaved.

7d 3h 30m planned has historically meant 8d 6h 13m

Capacity answers "does this fit?" from the numbers on the issues. This answers it from the numbers those estimates have turned into — and the interesting case is the window that fits on paper and has never fitted in practice, which a capacity check misses entirely. The page says so when that is what is happening.

Only issues whose hours were measured contribute, so the factor is silent until there is enough history. See Reports.

Burning down

Work remaining, one reading a day, taken by felagi:cycles each morning.

The readings are recorded, not reconstructed. This is the difference between this chart and most burndowns: reconstructing means today's estimates are applied to every past day, so re-estimating one issue from two hours to twenty on a Thursday moves Monday's point and the chart says the team was further behind at the start of the week than anybody thought at the time. Every tracker does this quietly, and it is why nobody trusts the chart.

Three lines:

The scope line is there because a cycle that grew mid-window is the usual reason a burndown never reaches the floor, and a chart that cannot show scope moving blames the team for it. When it has grown, the page says by how much.

Weekends are left out, for the same reason capacity leaves them out: a line expected to fall on a Saturday makes every Monday look like a failure.

A missed day is drawn as a gap, and the line breaks either side of it. Two readings with a week between them are two observations, not a trend through the middle. Today's point is computed when you open the page rather than read back from this morning — a chart up to eleven hours stale is one you check against the issue list and stop believing.

A window with fewer than two readings shows no line and says why. Anything else would be a plausible drawing of days nobody measured.

How much usually gets done

Velocity, from closed windows only. A cycle halfway through has a partial number that looks like a bad one on a Tuesday, and an average built from partial windows means nothing.

Both counts and hours, because they disagree in a way worth seeing: a team that finished twelve issues instead of fifteen but the same number of hours took on bigger work, not less of it.

The range matters more than the mean. "14 on average" out of 4, 22 and 16 is a different promise from the same average out of 13, 15 and 14 — only the second team can plan. Range rather than a standard deviation, because nobody in a planning meeting has an intuition for a sigma.

Under three closed cycles, the page says so rather than presenting a confident average over two windows. Each bar shows what a window finished and what was carried out of it, with the current window's plan beside them: an average with nothing next to it is trivia.

Not there yet

• A burndown starts the day cycles were switched on. Readings cannot be taken retroactively, so a window that ran before then has no line.
• Velocity is an average and a range, not a forecast. Nothing extrapolates a finish date from it, because a range wide enough to be honest is too wide to schedule against.
• No burndown or velocity over the API, and neither is in the CSV export.
• 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.
• Capacity does not plan. Starting an issue puts it in the current window (above), but nothing looks at what fits and fills a window from the backlog. The comparison is a check on a plan, not a planner.
• Nothing takes work back out. An issue moved from In progress back to To do keeps the window it was planned into — it is still this fortnight's work, stalled, and that is worth seeing rather than tidying away.