Sprint planner
What Heimdall reads before it proposes a scope for a sprint, the rules it plans by, how its answer is checked against the candidates before you see it, why nothing is planned until you tick it, what a proposal costs and where it stops.
By the end of this page you will know how Heimdall's sprint planner thinks: what it is given, the rules it plans by, how it must answer, how its answer is checked before you see it, what a proposal costs, and the lines it never crosses. The task itself, pressing Plan with Heimdall on a sprint and ticking the items into it, is on the sprints page of the building guide; the sibling assist that sizes one item is on the estimation page.
What Heimdall is given
The planner has no tools and no memory of earlier turns. Everything it knows arrives in one brief, written the same way every time and read through the same services the Sprints page reads through, so it sees nothing the person who asked could not open:
- The sprint: its name, the project, its status, its goal as plain text, its dates, the project's working days, and its capacity in points and in hours, each marked not set when it is.
- The recent velocity: the average velocity of the last three closed sprints that recorded one, or the word that no sprint has closed yet.
- The candidates: every open backlog item in no sprint, in the backlog's own order, up to sixty of them. Each line carries the item's id, its reference and title, its kind, its priority, its story points and its estimate in hours when it has them, its due date, whether its Definition of Ready is complete (and how many required entries are still unticked when it is not), its epic, and the open items that block it, read from the links that say one item blocks another or depends on it.
A candidate without points is shown as such, and the planner is told what to do with it rather than left to guess a size. Points that are not a number on the project's scale, such as a T-shirt size, count as unsized in the totals.
The rules it plans by
The planner is briefed for the project manager who will decide the scope, and given six rules in the order they win:
- Stay within the capacity in points when one is set; when none is set, within the recent velocity; when neither is known, propose a modest scope and say so. Hours count only when points are missing.
- Take items in priority order, but take an item due within the sprint's dates ahead of its priority.
- Prefer items whose Definition of Ready is complete; take an unready item only when it is urgent, and say it must be made ready first.
- Never take a blocked item unless its blocker comes too; when the blocker is not a candidate, leave the item out and name the blocker.
- Keep an epic's items together when they fit; take an unpointed item only when the capacity is counted in hours or nothing else fits.
- Prefer a coherent scope over a full one: a sprint should end with its goal met.
It refers to candidates by their id, never by title, and is told never to name an item that is not in the list. Every picked item gets one sentence a developer would accept; every item left out gets one sentence naming the rule; the risks are what could still go wrong with the scope it picked; the summary is two or three sentences on what the sprint would deliver, how full it is, and the biggest risk.
How it must answer
The answer is a fixed shape, not prose: a summary, the items in the order to take them (each an
id and a reason), the left_out items with their reasons, and up to five risks. The shape is
held on the model's side, so the planner cannot add a field, skip one or answer in a paragraph.
How the answer is checked
Nothing the model names reaches you unchecked:
- an id that is not among the candidates is dropped, so an invented item never appears;
- an id named twice keeps its first mention, and an item picked for the sprint is not shown again among the ones left out;
- every reason is kept as plain text and trimmed, and the risks are capped at five;
- the points picked are added up from the candidates' own points, never from anything the model wrote, and shown against the capacity and the velocity.
What survives is the proposal you see: the picked items with their facts (reference, title, kind, priority, points, due date, whether ready, what blocks them) and the model's reason beside each, the items left out with theirs, the risks and the summary.
What is written and what is not
The planner writes nothing. The proposal opens in its own flyout with every picked item ticked;
untick what you disagree with and press Add to Sprint, and the items go through the same scope
action the plan dialog uses, so the project's Definition of Ready gate holds as it would by hand
and sprint.scope_changed goes out as it would by hand. Discard drops the proposal and leaves
the sprint as it was. Over the API and the MCP server the proposal comes back as data, and an
agent plans the items the person agrees to through the item's own sprint field.
Ask once, then plan
Every proposal is a metered call, and the backlog does not change between two asks a minute apart. Read the reasons, change your mind on a tick, and plan; ask again once the backlog or the capacity has moved.
What a proposal costs
Each proposal is one metered call under the team's AI budget, filed as Sprint planning with the project, the person who asked and the model's tokens; the budget is asked for room before the model is called, and a team past its cap gets a refusal, not a proposal. The planner runs on the workspace's involved model role, the one for work that weighs several things at once, and gives up after ninety seconds rather than keep you waiting.
Where it stops
- It never plans, starts, closes or cancels a sprint; the items join on your tick, through the same action as the plan dialog.
- It proposes only for a planned or running sprint; a sprint that is with the team, completed or cancelled is refused, as is a backlog with nothing left to plan.
- It runs only for staff with
ai:usewho may change items on the project, on a project whose assists are on, within the team's budget; a client guest never sees the button. - It reads through the person's own visibility, so it weighs the same candidates the plan dialog would offer them.
- A provider that does not answer leaves the sprint untouched and files nothing; the message says Heimdall was unavailable.
Related
- Sprints — the button, the flyout and the tick that plans
- Estimation — the points the planner counts, and Heimdall's size suggestions
- Definition of Ready and Done — the readiness the planner reads
- Usage and budgets — where every proposal is filed
- suggest_sprint_scope — the same proposal on an agent's word
- Sprints API — the proposal over REST
How is this guide?
Last updated on
Quality review
What Heimdall reads before it judges a record, how it grades and codes a finding, why the score is arithmetic, what a review costs and where it stops: it never writes to the record.
Brief import
What Heimdall is given before it reads a brief, how it fills each kind of suggestion from one uniform row, how it judges its own confidence, why it runs on the queue as you, what it costs and where it stops.