Planning Agent

A starting proposal for sprint planning

Frankee reads your current sprint, your next sprint, and the top of your ranked backlog, then proposes a plan and explains its reasoning. It is a first draft to argue with, not a plan to adopt. The parts it has not assessed are stated on the page, every time.

What it can and cannot do today

This is an early release. The honest boundaries:

• It reads your tracker. It never writes to it. Nothing is created, moved, assigned, or added to a sprint in Jira or Azure DevOps. Acting on a proposal means doing it yourself in your tracker.
• Sprint-based teams only. Kanban teams are told the feature is not for them rather than being handed a sprint plan for a team that does not run sprints.
• It does not estimate, size, or schedule. There is no capacity model behind the recommendation.
• It is not a conversation yet. You generate a proposal and read it. You cannot ask it to revise the plan.

Generating a proposal

Go to Team Events › Planning Agent and choose your team. Opening the page resumes your last proposal if one is still open; it never regenerates on its own, so a plan you were reading is not replaced while you look at it.

Generate a fresh proposal re-reads your tracker. If you moved work in Jira or Azure DevOps since the last run, this picks it up. Proposals expire after 24 hours, on the grounds that a plan built on yesterday's board is not a plan.

Frankee reads up to 200 items from each sprint and the top 50 of your ranked backlog. Where a read was cut short it tells you, so you know the proposal was built from a partial view.

What Frankee works out first

Before proposing anything, Frankee states the situation it is reasoning from. This is shown on the page so you can disagree with the premise rather than only the conclusion.

CREATE or REVIEW

• CREATE means your next sprint is essentially empty and Frankee is proposing a plan from scratch.
• REVIEW means work is already in the next sprint and Frankee treats it as your draft, offering a second opinion instead of replacing it.

The threshold is three items: fewer than three in the next sprint is CREATE, three or more is REVIEW. One or two tickets dragged forward is usually how a team parks work, not a plan. The threshold is shown on the page so you can see the rule and disagree with it.

The goal it planned around

Frankee looks for a goal on the sprint being planned, never the one currently running: borrowing the running sprint's goal would attribute a commitment to your team about different work. Placeholder values such as "TBD" are treated as no goal at all.

• Your goal. A real goal was set on the sprint and the plan is built around it.
• Frankee's inferred goal. No goal was set, so Frankee proposed one from the work it can see, and shows the evidence it used. This is styled differently from a real goal on purpose. It is a suggestion about what your sprint might be about, not something your team agreed.
• No goal. Nothing was set and nothing could be inferred with confidence. Frankee says so rather than inventing an anchor.

The three strategies

Frankee names the strategy behind its plan and explains in a sentence why it fits.

• GOAL LED. There is a goal and most candidate work serves it. The plan is organised around achieving it.
• SCOPE LED. There is no goal, so the plan works from ranked priority instead. A plan with no goal is always scope-led, because the alternative is a plan built around an anchor nobody set.
• HYBRID. There is a goal, but only some of the available work serves it. The plan pursues the goal and names the other work explicitly rather than blending it in, so you can see what is being recommended despite not serving the goal.

Where a goal exists but nothing in the backlog clearly relates to it, Frankee chooses HYBRID and flags the signal as ambiguous rather than claiming goal alignment it cannot support. Treat that as a starting point for discussion.

REVIEW mode: a second opinion on your draft

When your team has already started planning, Frankee shows your draft as the baseline and sorts it into four buckets. The fourth is the one that matters most.

• Would retain. Draft items Frankee would keep, with the reasoning.
• Would question. Items it would challenge, each with a specific reason. Questioned items stay in the plan; they are not removed on your behalf.
• Would add. Work not in your draft that Frankee thinks belongs.
• Could not assess. Draft items Frankee did not evaluate, or argued both ways about. These are kept separate from "would question" deliberately: no assessment is not the same as a concern, and filing them as concerns would mean inventing a rationale. An item here has had nothing said about it, which is different from being approved.

The recommendation is derived from that review: what Frankee would retain, plus what it would add, in your draft's original order. The order your team put the draft in is itself a decision, and it is not resorted.

Where the next-sprint read was cut short, Frankee says how many items went unassessed rather than letting a partial review look complete.

What Frankee has not evaluated

Every proposal carries three callouts, always all three, whatever the plan says. They sit above the recommendation because they qualify everything below them, and they cannot be dismissed.

• Readiness: not yet evaluated. Items have not been checked against your Definition of Ready. Some may not be ready to start.
• Dependencies: not yet evaluated. Frankee has not looked for dependencies between these items or on work outside the sprint. Some may be blocked.
• Capacity: not yet evaluated. The selection has not been compared with your team's capacity. This may be more work than the sprint can hold.

These are written by Frankee itself rather than generated, so no change to how the plan is produced can quietly drop one. An omitted warning would read as a dimension that passed.

Reading the proposal well

• Start with the situation, not the list. If Frankee has the mode or the goal wrong, the plan below it is answering the wrong question, and that is faster to spot than checking ten items.
• Check whether the goal is yours. An inferred goal is Frankee's guess. If it is a good guess, consider setting it as a real sprint goal.
• Read "would question" and "could not assess" first. The retained items are the ones you already agreed on.
• Take it to planning, do not take it as planning. A proposal that skips the readiness, dependency, and capacity conversation is not a sprint plan.

If something does not work

• Kanban teams. The entry is visible but disabled, and the page explains that sprint-based planning is what this release covers. It is shown rather than hidden so a missing feature does not look like a missing capability.
• Tracker not configured. Jira teams need a board ID and Azure DevOps teams need their Azure DevOps team set, because sprints and iterations resolve through those. See Integrations.
• Your session expired. Proposals last 24 hours. Generate a fresh one.
• A proposal with no plan. The tracker read succeeded but generation failed. Try again; the situation shown is still accurate.