Skip to main content
Project Intelligence

Schedule Planning

After tickets (and, as a rule, their estimation), the backlog becomes a plan. In the system, this is two agent commands: /estimate for estimation and /plan with three modes — sprint, release, Gantt.

Input: ready tickets (see Gathering and elaborating requirements).

Step 1. Estimation: /estimate​

First run: the estimation method​

On the first run, the agent:

  1. Discovers which estimate field is actually available in your tracker project (story points, time tracking, or another) — for the specific issue types.
  2. Asks a short question about units: story points, person-hours, t-shirt sizes (S/M/L), or qualitative estimates; and about the scale (e.g., L = 5 points).
  3. Saves the choice to the estimation method document (estimation-method.md) with review.

If the project has no estimate field on its screens — the agent says so instead of substituting someone else's field. Adding the field is a tracker-configuration action.

Per-ticket estimation​

/estimate              — show candidates (unestimated first) and walk them
/estimate PI-42        — one issue
/estimate sprint "S12" — the sprint queue
/estimate release 1.2  — the release queue
/estimate backlog      — the backlog queue

For each issue the agent reads its description (and related documents), gives advice — whether the issue fits a single working session, a recommended value, and why — then waits for your confirmation. An issue that does not fit a session is a split candidate (/tickets).

Writing an estimate to the tracker is a proposal only: you see what will be written and apply it.

Step 2. Planning: /plan​

One command, three modes — the agent infers the mode from context, or specify it explicitly.

Sprint mode: /plan sprint​

Filling one sprint with capacity math:

  • Capacity is computed as: team size × sprint length × focus factor (default 0.7 — the agent states it), minus PTO, on-call, ceremonies. Numbers are not invented: team and cycle length come from the project profile or from you.
  • Carry-over from the previous sprint consumes capacity first; if carry-over exceeds ~30% of capacity, the agent flags an over-commit risk.
  • DoR (definition of ready): an issue without a clear outcome, testable criteria, an estimate, or known dependencies goes to "needs refinement", not the commit.
  • Result: a sprint plan with tables — capacity (calculation steps), sprint goal, committed, stretch (pull in if we make it), and deferred with reasons.
  • Assigning issues to the sprint in the tracker — proposals only.

Release mode: /plan release​

A release cut:

  • the agent finds (or proposes creating) the version in the tracker,
  • splits candidates into "in release" and "deferred" (with the next cut),
  • builds the milestones: code complete → RC → GA, with dates (assumptions flagged),
  • notes risks and dependencies and prepares a lightweight sign-off checklist.

Result: the release plan. The version, dates, and issue-to-version links — proposals only.

Gantt mode: /plan gantt​

The top-level project schedule in three phases — in order, no skipping:

  1. Dependency network. Nodes are features, epics, releases (not every ticket): children roll up into their "umbrella". Edges are finish-to-start. The agent shows the network and checks: are the nodes and edges correct?
  2. Durations. For each node — calendar duration: effort (sum of children's estimates) ÷ (team × focus × throughput). Before the chart, a duration table is published — with explicit assumptions where the rate is unconfirmed.
  3. Chart. A top-level Gantt from the anchor start date, the critical path (the chain that sets the finish date), and risks and buffers.

Result: the timeline.md document (network + durations + Gantt). When you accept the schedule as the baseline, the agent freezes a dated copy timeline-baseline-YYYY-MM-DD.md — a baseline is never overwritten; new snapshots get new dates.

An important distinction: /plan gantt is a planning document (in your materials). The live BeOnTime schedule is a separate working surface — see Working with the schedule editor.

What the agent does not do​

  • Does not invent capacity, velocity, or estimates — everything is computed from confirmed data or explicitly marked as an assumption.
  • Does not add new work silently. New work outside the approved scope passes /scope-check first (see Scope control) — only then is the plan extended.
  • Does not write to the tracker behind your back — sprints, versions, due dates, estimates: everything through proposals.

Where to continue​