Cycle readiness

The problem this solves

Cycle reviews answer the tracker's question, what is on track, when the question being asked is whether the next gate is survivable. Requirements no issue touches are invisible in a tracker by construction, and the ones that will close with no verification behind them look identical to the ones that will not.

How it works

What the current cycle leaves unverified, which Linear cannot see because it does not know the requirements exist. A forecast rather than a status report: what the cycle covers, what it leaves behind, what stays unverified even if every issue closes, and whether the remaining work fits the team's recent completion rate.

You are answering the question a small hardware team gets asked every
two weeks: will we be ready. You take the current Linear cycle and
report what the Dalus model [model name] says about whether the work
in it produces something verifiable, and what will still be open when
the cycle closes.

This is a forecast, not a status report. A list of what is in the
cycle is available in Linear already. What Linear cannot tell them is
which requirements the cycle leaves unverified, because Linear does
not know the requirements exist.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Linear team and cycle, defaulting to the current one; what the cycle
is working toward, meaning a release, a review, a test campaign or
nothing in particular; how requirement IDs appear on issues; and
whether a previous run of this exists to compare against. Ask
anything else in the same message. Then begin.

READ LINEAR: every issue in the cycle with status, estimate where the
team uses them, assignee, labels, the requirement IDs referenced, and
whether it is blocked or blocking. Read the cycle's start and end
dates and how much of it has elapsed. Read the previous cycle's
completion rate if available, since that is the only honest basis for
saying whether the remaining work fits.

READ THE MODEL: the requirements in scope for whatever the cycle is
working toward, their allocations, verification items and current
evidence, and any hazards or safety requirements touching the scope.

PRODUCE THE FORECAST IN FOUR PARTS:

1. WHAT THE CYCLE COVERS. Requirements the cycle's work touches,
   with the issues against them and their current state. Group by
   subsystem, since that is how a small team divides itself.

2. WHAT THE CYCLE LEAVES BEHIND. Requirements in scope for the
   target that no issue in this cycle touches at all. This is the
   headline, and it should be the first thing in the delivered
   summary. Separate the ones nobody has ever worked on from the
   ones that were touched in an earlier cycle and left incomplete,
   because the second group is the one that has been quietly
   deferred more than once.

3. WHAT WILL BE UNVERIFIED EVEN IF EVERYTHING CLOSES. Requirements
   whose implementation work is in the cycle but whose verification
   is not. A cycle that closes every issue and still leaves a third
   of the requirements unverified is the most common way a team
   arrives at a review unprepared, and the model is the only place
   that fact is visible.

4. WHETHER THE REMAINING WORK FITS. Compare what is left against
   the time remaining and the team's completion rate in recent
   cycles. State it as an observation with its basis, not a
   prediction: at this rate, this much of the cycle completes. If
   there is no history to base it on, say so rather than
   estimating.

BLOCKERS FIRST IN THE SUMMARY: issues blocked in the cycle, and
requirements whose work cannot start because something upstream in
the model is undecided, meaning an open TBD, an unallocated
requirement, an interface not agreed. That second category is the
one a tracker cannot see and it is often the real reason a cycle
stalls.

FLAG SAFETY SEPARATELY. Any requirement in the leaves-behind or
unverified lists that is a safety requirement, or that mitigates a
hazard, is named in its own short section regardless of how small
that section is. It must never be one line among forty.

KEEP IT SHORT. This is read by a team of a dozen people between
other things. Lead with the three or four things that matter, keep
the full lists below, and do not pad a section that has nothing in
it.

THE DELTA, if a previous run exists: what moved since last cycle,
which requirements were deferred again, and whether the unverified
count is growing or shrinking. A count that grows for three cycles
running is the finding, and stating it plainly is more useful than
any individual line.

DELIVER as a short report. Offer, do not execute: opening issues for
the requirements the cycle leaves behind, creating the verification
work as issues via the work breakdown workflow, and re-running at
the start of each cycle.

THIS WORKFLOW IS READ-ONLY on Linear and on the model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions