Planning Agent

A starting proposal for sprint planning

Frankee reads your current sprint, your next sprint, and your backlog, then proposes a plan and explains its reasoning. It checks every item in that plan against your Definition of Ready, offers to draft the missing content where it can, and reads the dependency links already recorded in your tracker. It is a first draft to argue with, not a plan to adopt, and 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 writes exactly one thing, and only when you ask. Accepting a drafted readiness fix posts it as a comment on that work item, marked as written by Frankee. Nothing else: no item is created, moved, assigned, reordered, or added to a sprint, and nothing your team wrote is ever edited or deleted. Acting on the rest of 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 or schedule. Frankee never puts a number on an item that does not have one. It reads the estimates your team recorded, and it compares their total against your capacity. It does not size the work, sequence it, or decide who does it.
• 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.

Before it runs any checks, Frankee confirms that your tracker has a next sprint to plan into. If your Jira board or Azure DevOps team has no upcoming sprint yet, the page shows Create your next sprint first and tells you to create it in your tracker and come back. Nothing is checked and no AI credits are used, because a plan with nowhere to land cannot be approved. The sprint only has to exist: one with no dates or capacity set yet still counts. When there is more than one upcoming sprint, Frankee plans the same one it reads everywhere else on this page: the earliest by start date, or, when none has dates, the first in your tracker's list.

Frankee reads up to 200 items from each sprint and the top 50 of your ranked backlog. When the sprint has a goal, it also scores your whole backlog against it, as described below. Where a read was cut short it tells you, so you know the proposal was built from a partial view.

What Frankee leads with

Once every check has finished, the proposal opens with one headline: the finding most likely to affect your plan. Everything else Frankee found is listed under it, in order, and the detailed checks are one click away under Planning baseline details. Nothing is hidden or dropped to make the headline. While checks are still running, the headline space says so instead of guessing.

How the headline is chosen

Frankee does not score or predict anything new here. It places each finding the checks already produced on a fixed ladder, and the highest one leads. Most material first:

1. Goal coverage is Low: the planned work is unlikely to achieve the sprint goal.
2. A planned item is blocked: it depends on work that is not in the plan, a dependency Frankee could not resolve, or a dependency loop.
3. The plan asks for more than 20% above what the team delivers.
4. Unfinished work in the current sprint is at risk of carrying over and is not in the next sprint's draft.
5. Goal coverage is Medium, or the backlog holds goal-related work the draft does not include.
6. Most planned items are not ready against your Definition of Ready.
7. Some planned items are not ready.
8. The plan asks for more than 20% below what the team delivers.

Readiness sits low on purpose. Definition of Ready gaps are common and often small, so they should not crowd out a problem that will change the sprint.

When a check could not answer

A check that failed (it ran and hit an error) is placed where its worst result would have been, because Frankee cannot rule that problem out. A failed dependency check can lead the summary. A check that was unavailable (it could not run at all, for example with no completed sprints to compare against) is listed below every problem Frankee did find, and is never treated as a pass.

When two findings are equally important

Ties on the same rung are broken the same way every time:

1. A confirmed finding comes before missing evidence.
2. Then the finding that affects more planned items.
3. Then a fixed order: Readiness, Dependencies, Carryover, Capacity, Goal.
4. On rung 5, the goal coverage rating comes before goal-related backlog work.

A clean plan

If nothing on the ladder applies, the headline says the plan looks ready. If a check could not run, it says no problems were found in what Frankee could check and names what was not checked.

How Frankee decides what to investigate

Frankee does not run the same fixed checklist on every sprint. It works in two stages, and the second depends on what the first found.

1. The planning baseline. Four checks run on every plan, at the same time: Readiness, Dependencies, Carryover and Capacity. Frankee never decides to skip one of these.
2. Investigation. Once the baseline has finished, Frankee chooses which further checks are worth running, given what the baseline found. Today there are two: rating how well the plan covers the sprint goal, and searching the whole backlog for goal-related work the plan does not include. It can run both, one, or neither, and it says why for each choice.

Which further checks are on offer depends on the sprint's situation, so the path differs from sprint to sprint.

An empty sprint with a goal

Example: the next sprint has nothing in it yet (fewer than three items counts as empty, see below), and its goal is "Shoppers can save and reuse cards". Frankee first scores your whole backlog against the goal, then builds the plan from the work that serves it best, then runs the baseline. Afterwards it can rate how well the plan covers the goal. It does not search the backlog a second time, because the plan was built from that search.

A sprint that already holds a draft, with a goal

Example: your team has already put eight items into the next sprint, and its goal is "Speed up repeat checkout". Frankee reviews your draft, runs the baseline, then decides what else to look at. Usually it rates goal coverage first. If the rating is High and nothing is named as missing, it may stop there, since searching the backlog for goal work would find nothing the plan needs. If coverage is lower, or something is named as missing, it usually goes on to search the backlog for goal work your draft leaves out.

A sprint with no goal

Example: the next sprint has no goal set, and nothing in it points to one. Frankee builds the plan from the top of your ranked backlog (or reviews your draft), and runs the baseline. Goal coverage and the backlog search are both skipped, with the reason "no sprint goal set", because there is no goal to measure against.

A goal Frankee inferred from the work counts as a goal here, and the page says that it is Frankee's reading rather than your team's. If Frankee cannot decide what to look at next (a temporary problem on its side), it runs the standard checks for the situation instead, and the evidence trail says so.

Reading the evidence trail

At the foot of the plan, How Frankee investigated this plan opens the evidence trail. It is closed by default, because the headline and the findings above it are what most people need. Open it when you want to know exactly what Frankee looked at.

Each step is its own entry, so a long trail stays easy to scan. An entry shows:

• What was checked, as the entry's title, with its result as a label beside it.
• Why it was relevant. For a check Frankee chose, this is the reason it gave.
• Source: what it read, such as your tracker's comment threads or your team's completed sprints.
• Found: what the check found, or why it could not answer.
• Retrieved: when the evidence was read (Attempted for a check that failed). For Carryover and Capacity this is when your planning session began, because they work from what Frankee read from your tracker at that moment.

A step that did not run is listed too, with Reason in place of Why: "no sprint goal set", "Frankee judged it unnecessary because goal coverage was rated High with nothing missing", "Frankee judged it unnecessary given what the required checks found", or that a limit stopped it. A step you asked to run again shows its latest result and says it was run again at your request.

The trail is saved as it happens. If you come back to the plan later, it says exactly what it said at the time, even if your tracker or the plan has changed since. It shows what Frankee decided and what it found, never Frankee's internal reasoning.

Confirmed, unavailable, failed, or not yet checked

Every finished check on the page, in the planning baseline and in the evidence trail, carries one of four labels. They look different on purpose, so that a check Frankee could not do is never mistaken for one that passed.

• ✓ Confirmed. The check ran and reached a definite answer, which is shown with it. This is the only label with a tick, and the only one you can rely on as a result.
• ⊘ Unavailable. The check could not run, or ran and could not reach an answer, because what it needs is not there: no Definition of Ready, no completed sprints to compare against, items with no estimates, capacity turned off, or a goal too vague to rate. The reason is always stated. Treat that part of the plan as unchecked.
• ✕ Failed. The check ran and hit an error, such as your tracker not responding. The reason is given in plain words. The problem it was looking for has not been ruled out, so treat it as unchecked, and generate a fresh proposal later if it matters.
• ○ Not yet checked. The check has not run yet. This is normal for the first moments after a plan appears; while a check is running it shows as … Checking. A check that was not run at all shows the same ○ symbol, labelled Skipped, with its reason.

When a baseline check is unavailable or failed, the top of the plan says which part of the plan is affected and what that means. For example: "Capacity could not be checked: Frankee has not compared the plan with what the team delivers, so the plan may be more or less than the team can finish." Frankee never calls a plan ready while one of its checks failed or could not answer; it says what was not checked instead.

A check can also be confirmed for most of the plan but not all of it, for example when the dependency links for one item could not be read. The check stays confirmed for the rest, the unread items are named, and the plan is not called ready while they remain unchecked.

These labels are worked out afresh for each planning session. A check that was unavailable last sprint is checked again on the next proposal.

One boundary is worth knowing. The dependency check reads the links your team has recorded in the tracker and the planned items' own text. A dependency nobody wrote down or linked is invisible to it, so a plan with no dependency notices means neither the links nor the text showed one, not that nothing is blocked.

When an investigation stops early

Every investigation has two limits, so it cannot run on indefinitely:

• Steps: at most 8 checks in one investigation, the four baseline checks included.
• Time: at most 9 minutes of active checking. Time while the page is closed does not count. Frankee only starts a check if it can finish inside the time left, so nothing is ever cut off halfway.

The limits only apply to the further checks Frankee chooses. The four baseline checks always run. On a typical plan neither limit is reached.

If a limit is reached, a note appears on the page, outside the evidence trail, for example: "Frankee stopped at its time limit of 9 minutes for one investigation. Everything already found is shown in full. Not completed: Find goal-aligned work in the backlog." In the trail, each check that did not run is listed as skipped, with the limit as its reason.

There is no spending limit partway through. Frankee checks your organization's AI credit once, when an investigation starts, and never stops a running one for credit, because a half-checked plan with no explanation would be worse than finishing. If your organization has already used its credit for the month, the investigation does not start, and the top of the plan says so: "Frankee could not check this plan: your organization has used its AI credit for this month." It names the checks that did not run. If the proposal is still open when your credit resets, they run when you next open it; proposals expire after 24 hours, so otherwise generate a fresh proposal.

If your browser loses its connection partway through, or you close the page, nothing already found is lost. A check that was cut off shows as ! Interrupted, and coming back shows what finished and a Continue investigation button to carry on.

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.

Building a new plan, or reviewing your draft

• Building a new plan means your next sprint is essentially empty and Frankee is proposing a plan from scratch.
• Reviewing your draft 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 means building a new plan, three or more means reviewing your draft. 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.

How a plan without a goal is filled

When you are building a new plan and the sprint has no goal, Frankee fills it from the top of your backlog, in priority order, up to what the team can deliver. It takes items in turn and stops before the first one that would take the plan over the team's expected capacity; it does not skip that item to look for smaller ones further down. Work already in the next sprint comes first. An item with no estimate counts as nothing, so it always fits. There is no fixed number of items: the capacity is the limit.

The number is the one the capacity check shows: the figure you entered in points, otherwise the team's historical median adjusted for this sprint's availability. The investigation trail's plan step says the plan was filled to capacity and gives the number. If the first item alone is bigger than that, the plan is empty and says so.

With no capacity to work to (no completed sprints, capacity turned off, a figure in hours, a capacity of zero, no estimates on any backlog item, or Azure DevOps, where Frankee has not verified which field holds the estimate), the plan is built as before, up to ten items, and capacity shows as not evaluated. A plan with a goal, and a review of a sprint that already holds work, are never cut to capacity. To fill to a figure you enter, choose it above the Generate button before generating. Capacity entered or changed after the plan is built does not refill it; generate a fresh proposal to fill it to the new figure.

Where a goal exists but nothing in the backlog clearly relates to it, Frankee chooses Hybrid and says it is unclear how much of the work serves the goal, rather than claiming goal alignment it cannot support. Treat that as a starting point for discussion.

The Definition of Ready check

Once a proposal exists, Frankee checks every recommended item against your team's active Definition of Ready and puts a status on each one. This runs as a second step, so the plan appears first and the badges fill in behind it.

The three statuses

• Ready. Every criterion that applies was checked and every one passed.
• Not Ready. At least one criterion was checked and the item falls short. The badge shows how many gaps, so one gap and four gaps do not look alike.
• Cannot Fully Assess. Nothing failed, but at least one criterion could not be checked. This is deliberately not the same as Not Ready. An item with six criteria met and one unreadable has not failed anything; Frankee simply could not see enough to call it ready.

An item is only as ready as its weakest applicable criterion, and "Ready" means every one was checked and passed. An unassessable criterion can never disappear behind six good ones.

What Frankee reads

Frankee reads the item's description, its acceptance criteria field where your tracker has one, and its comment thread. A criterion answered in a comment is answered: there is no lesser kind of evidence, and it makes no difference whether your team wrote it or Frankee posted it there as an accepted fix. If a discussion in the comments settled something the ticket body never said, the item is judged on that too.

If Frankee could not read an item's comments, it says so rather than assuming there were none. The item is still checked against everything else on it, and the missing thread is never treated as evidence that your team has not discussed something.

A very long thread is cut to its most recent comments, since that is where a discussion usually lands, and the check notes how many were left out.

Which criteria get checked, and how

• Always-include criteria are checked on every item.
• When-relevant criteria are checked only where they apply. A rollback strategy is a real gap on a data migration and is simply not relevant to a copy change, and Frankee marks it that way rather than counting it against the item. Criteria set aside as not relevant do not affect the status.
• Human-confirmation criteria always read as unassessable. Frankee does not attempt them, for the same reason it never injects them into story generation: whether your whole team understands a story is not something an AI can attest to.
• Some answers come from the item's fields, not from AI. Whether a priority is set, for instance, is a fact Frankee reads rather than a judgement it makes. Those are answered before any AI call and cannot be overturned by one.

Expanding Definition of Ready on an item lists every criterion by the exact title your team gave it, with a specific sentence on what is present or missing. Nothing is paraphrased and nothing is truncated away.

If your team has no active Definition of Ready, or has one with every criterion switched off, the plan says so plainly instead of showing statuses. Neither is an error and neither blocks anything.

Draft fixes for the gaps Frankee can close

Each gap is labelled with how it can be resolved, and the two are genuinely different kinds of problem.

• Frankee can draft a fix. The gap is that something is unwritten or too vague, and better content on the item would close it: missing acceptance criteria, an unstated failure case, a thin description.
• Needs team input. Closing it needs a decision, a fact, or knowledge that is not on the item: a priority, an estimate, a business rule, a technical approach, a dependency's mitigation. Better prose cannot supply any of those, so no draft is offered and Frankee does not pretend otherwise.

Draft a fix for this generates the missing content for that one gap, written from what the item already says. You then have three options:

• Accept and post to tracker. The draft is posted as a comment on that work item, marked as written by Frankee and naming the criterion it answers.
• Edit. The draft opens in a text box. Your version is what gets posted, and the record shows it was your wording rather than Frankee's.
• Dismiss. The draft is discarded and the gap stays flagged. Saying no to a draft is not the same as resolving the gap.

A few things worth knowing about the write:

• It is a comment, never an edit. Frankee adds to the conversation rather than rewriting a description or an acceptance criteria field your team wrote. Nothing existing can be lost.
• The item is re-checked immediately before posting. If it has been rewritten in your tracker since Frankee read it, the push stops and says so rather than commenting against a version that no longer exists.
• A failed push leaves nothing behind. The gap stays exactly as it was and you can simply try again.
• There is no undo in Frankee. To retract a posted fix, delete the comment in Jira or Azure DevOps.
• One draft per gap. Generation is single-shot; a gap you dismissed is not drafted again.

Once a fix is posted, that criterion is resolved and stops counting against the item. An item with four gaps and one fix posted is still Not Ready: the status only turns Ready once every gap is closed.

Dependency notices

Frankee reads the dependency links your team has already recorded in Jira or Azure DevOps for every item in the proposal, and shows what it found on that item's own card. There is no separate dependency report: a dependency matters while you are looking at the item it blocks.

Only what an item waits on is shown. A link saying this item blocks something else, or is merely related to it, is not something the sprint is waiting for, and listing those would bury the ones that matter.

The two kinds you can do something different about look different. A missing same-team dependency is amber, because it is work your team could choose to pull into the sprint. An external one is set apart in its own colour with a marked edge, because resolving it means a conversation with somebody else. You should be able to tell which is which without reading the sentence.

Anything needing attention is listed first. Dependencies that are already met or already in the plan sit below them in a quieter style, so you can confirm the plan hangs together without them competing with the ones that do not. Nothing is collapsed or hidden behind a click: however many findings an item has, they are all on the card.

The dependency check runs just after the plan appears rather than holding it back, so for a moment you may see Checking dependencies… on an item. That is Frankee still looking. An item with no notice and no message has been checked and has nothing to report.

Findings are checked once and then kept with the proposal. Step away and come back within the session's 24 hours and they are exactly as you left them, with nothing re-run and nothing re-spent. That also means they are a point in time: the plan says when the check happened, and if a teammate has since linked or finished something, it will not appear until you generate a fresh proposal.

The notice types

• Not in this plan. The dependency is in your team's backlog, is not finished, and is not one of the items this plan recommends. Shown with its key, title and current status, and its estimate where Frankee has one. This is the only notice type highlighted in amber.
• Dependency met. The linked item is already done. Nothing to act on, and it is shown rather than hidden so you can see the check was made.
• Accounted for in this plan. The dependency is another item in the same proposal, so it is covered. Remove that item and this notice becomes Not in this plan on the next update, because it is worked out fresh each time rather than frozen when the check ran.
• Outside this team. The linked item sits outside your team's project or area path. Frankee names where it lives, shows its status if it has one, and says plainly that it cannot plan or verify another team's work. This stays flagged even when the linked item is already Done, because a delivered dependency you do not control is still one you had to coordinate; the status is shown so you can see it is likely satisfied.
• Inferred dependency. Your item's own text describes a dependency with no tracker link behind it: a vendor, an approval, an environment, another release, a business decision, infrastructure work, or a ticket somebody named in the description but never linked. Frankee quotes the words it read and labels the finding Inferred. See below.
• Could not check. Something specific stopped Frankee judging this one: the link points at an item that cannot be found, the item's status could not be read, the link type was not one Frankee recognises, or the tracker did not answer. The notice says which. It is never quietly reported as satisfied or as missing, because Frankee did not establish either.
• Circular dependency. Two items each wait on the other. Both are flagged, and Frankee does not attempt to untangle it: which one moves is a decision about your backlog.

What a notice does and does not do

A dependency notice is information, not an action. Frankee shows you the key, the title and the status so you can decide whether to pull the item in, drop the blocked work, or accept the risk. It does not add, remove, reorder or edit anything, in the plan or in your tracker, and there is no button on a notice that would.

Frankee also does not judge whether a dependency will be met, or whether the sprint is acceptable with it outstanding. That is your team's call, and it is one Frankee has no basis for: it can see that a vendor deliverable is mentioned and has no idea whether the vendor is reliable.

Estimates are shown only when Frankee actually has one, from the sprint and backlog it read. "It has no estimate yet" means the item genuinely carries no estimate. Silence about the estimate means Frankee did not fetch one, which is a different thing. Either way the notice still appears: a missing estimate is context, not a reason to stay quiet.

Confirmed and inferred

Every notice says where it came from, because the two kinds do not carry the same weight and you should never have to guess which one you are looking at.

• Confirmed means somebody recorded a real link between the two items in Jira or Azure DevOps. Frankee read it; it did not decide it. The evidence shown is the tracker's own words for the relationship, such as Linked in Jira as "is blocked by".
• Inferred means Frankee read your item's description or acceptance criteria and found a sentence describing a dependency. There is no link. The evidence shown is your team's own words, quoted exactly, so you can check Frankee's reading against what was actually written.

Both labels are words, not just colours, and the confirmed badge has a solid border while the inferred one is dashed. You should be able to tell them apart at a glance and in greyscale.

An inferred finding is a prompt to think, not a fact to act on. Treat it with less certainty than a tracker link, which is exactly why it is labelled rather than blended in with the rest. Frankee never resolves, adds or removes an inferred dependency for you.

A ticket mentioned in the text but never linked

If an item's description says something like "this depends on PROJ-99" and nobody ever created the link in your tracker, Frankee surfaces it as an Inferred dependency and shows the key. It is inferred rather than confirmed because a sentence is not a link, however specific it is: nobody recorded the relationship, so nothing in your tracker will keep the two items connected as the sprint moves.

Frankee will not report a key your item does not actually contain, and it does not treat a ticket that is merely mentioned in passing as a dependency. If the same ticket is both mentioned in the text and properly linked, you see it once, as confirmed.

How inference works, and what it will not do

Frankee reads each planned item's description and acceptance criteria and looks for dependencies on a vendor, an approval, an environment, a release, a business decision, or infrastructure outside your team. Work on another ticket is not included here, whoever owns it, because tracker links already cover that.

• It quotes, or it says nothing. Every inferred finding carries an excerpt from your item, word for word. If Frankee cannot quote the text a finding rests on, the finding is dropped rather than shown. Nothing is reported that you cannot check against your own ticket.
• It does not invent an owner. If your text says "depends on the API being ready" without naming a team, a ticket or a system, Frankee says the text does not name who owns it and leaves it there. It will not guess at a team name or make up an issue key.
• Finding nothing is the normal answer. Most items state no outside dependency, and Frankee is built to say so rather than fill the space. An invented dependency would send you chasing something that does not exist.
• An item with no description is not an item with no dependencies. If Frankee had no text to read, the card says so instead of showing a clean slate.

The status of an inferred dependency is never shown, because there is nothing to check it against. Frankee states that plainly rather than leaving the blank to be read as either good or bad news.

Removing items from the plan

Remove from plan drops an item from the proposal in one click. There is no confirmation dialog, because the action is reversible in one more click.

Removed items are never silently deleted. They move to a collapsed Removed items section at the bottom of the plan, struck through, with the reason recorded: the specific Definition of Ready gaps that prompted it, or a plain note that the item had no gaps. A plan that quietly shrank would leave your team with no record of a decision the plan exists to help you make.

Restore to plan puts an item back exactly as it was, with its readiness status, its gaps, and any posted fix intact. Removing changes nothing about the item except that it is out of the active count.

Removing an item does not touch your tracker. It affects the proposal on this page only.

Adding an item Frankee questioned or could not assess

When Frankee reviews a sprint you have already drafted, items it questioned or could not assess are not in its proposal, and approving and pushing the plan returns everything not in the plan to the backlog. If your team wants one of them in the sprint, choose Add to plan on it. It joins the proposed items marked Added by your team, and is in the sprint when you approve and push.

A questioned item keeps Frankee's reason for questioning it, shown on the item. An item Frankee could not assess is marked Not evaluated by Frankee: it has no readiness or dependency result, because Frankee did not check it, and adding it does not run any checks. The item stays listed where Frankee put it in the review, marked as in the plan. Remove from plan on an added item takes it back out, and it is offered for adding again.

When gaps are widespread

Item by item, a readiness gap is a small fix. Across a whole plan it is a different fact about the sprint, and nobody reading eight cards in sequence reliably notices the pattern. So Frankee says it once, at the top, above the item list.

The observation appears when either is true:

• More than half of the items still in the plan have at least one confirmed gap. The threshold is shown in the banner so you can see the rule and disagree with it.
• Gaps land on the work recommended for your goal, so the sprint is leaning on items that are not ready. Where a goal exists it is quoted exactly as your sprint records it, never paraphrased.

It updates itself as you work: remove items or post fixes, and it shrinks or disappears. Unchecked criteria never trigger it, because a claim about whether a sprint is committable must not rest on criteria Frankee never evaluated.

Reviewing your draft: a second opinion

When your team has already started planning, Frankee shows your draft as the baseline and sorts it into buckets. The last two matter most.

• Would retain. Draft items Frankee would keep, with the reasoning, that also meet your Definition of Ready.
• Would retain, but not ready. Items Frankee agrees belong in the sprint but which fall short of your Definition of Ready. They are shown here rather than under "would retain" so a readiness gap surfaces in the review conversation, and each one is labelled with where it came from. They carry the same gap detail, draft fixes, and Remove action as any other item. This is kept separate from "would question" on purpose: Frankee disagrees with a questioned item, and agrees with one of these but cannot call it ready. Post a fix that closes the last gap and the item returns to "would retain".
• 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.

The capacity check

Above the plan, Frankee states how much work it is proposing and how that compares with what your team can take on. The comparison is arithmetic over what your tracker already holds, or over a number you state yourself. Frankee never invents an estimate for an item that does not have one.

Three ways to answer "what can we take on?"

The control above the plan offers three, and it starts on the first:

• From past sprints. Frankee works it out. This is the default and needs nothing from you beyond a tracker with some completed sprints in it.
• Enter it myself. You state a number, in points or hours. Useful for a new team with no history, or when you know something the history does not.
• Do not check. No capacity reasoning and no callout. The plan is exactly what it was before this feature existed.

The choice applies to the planning session you are in, not to your team forever, and changing it takes effect immediately. Nothing is regenerated and no AI call is made.

Setting capacity before you generate

Before there is a plan, the same three choices appear above Generate Planning Proposal, so the plan is built against the capacity the team decided on. Choose Enter it myself to state a figure in points or hours first, and click Save capacity: Generate waits until the figure is saved, or until you choose one of the other two options. If you make no choice, Frankee works capacity out from past sprints, as it always has. Choosing makes no AI call and uses no credits; nothing is saved until you generate, and switching team starts again from the default. Your next sprint must still exist in your tracker when you click Generate.

Members' available hours for the sprint are still set once the plan exists, under From past sprints, because Frankee only reads your tracker, and so learns which sprint is next, when you click Generate. A figure in points that you choose before generating is also what a new plan without a goal is filled to.

Working it out from past sprints

Frankee takes the median points delivered across up to your last six completed sprints. Median rather than average, deliberately: one sprint where half the team was on leave would drag an average down for months, and the median describes what your team usually delivers, which is the question being asked.

Fewer than six completed sprints is not a failure. Frankee uses however many you have and says so, because a median over three sprints is a weaker claim than one over six and you are entitled to know which you are looking at:

Team capacity ~34 pts (historical median, based on the last 4 completed sprints). Proposed plan 41 pts. Over by 7 pts.

Only finished items count, and only the ones carrying an estimate. Work your team delivered without pointing it is left out of the total rather than guessed at, and if that is most of what a sprint delivered, the callout says so instead of presenting a partial total as a whole one.

Adjusting for the time you actually have

A sprint with two people on leave is not a normal sprint, and comparing its plan against a normal sprint's median is the wrong comparison. If your team's available hours are recorded, Frankee scales the number accordingly:

Reported capacity 180 hrs. Capacity at 75%. Full Velocity: 34 pts (median of the last 6 completed sprints). Expected capacity: ~25.5 pts. Plan 41 pts. Over by 15.5 pts.

That rests on two things, both optional. In Team Setup, each member can have Available Hours (per sprint), which is what they are normally available for. Then in the planning session, a team admin can override any member's hours for that sprint only, for leave, a public holiday, or someone splitting their time. The Team Setup default is never changed by an override: a fortnight off does not become someone's permanent hours.

• Leave a member's hours blank if you do not know them. They are excluded from the percentage and the callout says how many people that was. Frankee does not assume they are full-time, and does not assume they are absent.
• Zero means zero. A member fully out for the sprint is 0 hours, which is different from leaving it blank.
• Extra help is shown as extra. A contractor joining for one sprint pushes the percentage above 100%, and the expected capacity above your usual velocity. It is not capped, because the extra time is real.

Stating the number yourself

Choose Enter it myself, type a figure, and pick points or hours. It must be greater than zero. Frankee reads no tracker history at all in this mode, which is the point of it: a team Frankee cannot work a number out for still gets the comparison.

Team capacity entered as 30 pts. Plan 41 pts. Over by 11 pts.

Plans are measured in story points, so a capacity in hours is shown beside the plan but not compared against it. Frankee will not convert between hours and points, because the rate is your team's and it does not know it. You get both figures and a note saying so, rather than a number invented from an assumption.

The number moves when the plan does

The comparison is rebuilt every time you look at the plan. Remove an item and the total drops immediately; adjust someone's hours and the percentage follows. You will never see a callout describing a plan you have already changed.

Approving and pushing the plan

When the team agrees the plan, any team member can choose Approve and push. Frankee makes your next sprint in Jira or Azure DevOps match the plan:

• Every item in the plan that is not already in the sprint is added to it.
• Every item in the sprint that is not in the plan goes back to the backlog. That includes items you removed with Remove from plan, items Frankee questioned or could not assess when reviewing your draft unless you added them to the plan, and anything a teammate added to the sprint in your tracker after the plan was built.
• Items already in the sprint and in the plan are left as they are.
• Sub-tasks are left alone. Jira moves a sub-task with its parent, so Frankee moves the parent and the sub-tasks follow it. They are not counted in the confirmation or listed in the results.

Before anything moves, Frankee shows how many items it will add and how many it will return to the backlog, and asks you to confirm. Those counts come from when Frankee read your sprint. It reads the sprint again before moving anything, so the results reflect the sprint as it is at that moment.

Frankee changes your tracker only when a team member approves and pushes a plan. The only other thing it writes there is a fix you accept, added as a comment. It posts no comments when it moves items and does not change the sprint goal. Approving makes no AI call and uses no AI credits. Changed the plan after pushing? Approve and push again: Frankee runs the whole approval again against the plan as it now stands, and the sprint ends up matching the latest approval. Frankee keeps a record of each approval: who approved, when, what was proposed and approved, what happened to each item, and any readiness, dependency or capacity findings the plan showed at the time.

The results

When the push finishes, every affected item is listed under Not moved, Added to the sprint, Returned to the backlog, or Already in the sprint. An item that could not be moved says why in plain language, for example because it was deleted in your tracker or the connected account does not have permission to move it. Nothing that did move is undone, so you can move the rest by hand.

When Frankee will not push

If the sprint has been started in your tracker since the plan was built, Frankee shows Cannot push to active sprint and moves nothing. If the sprint has been closed or deleted, it says so and moves nothing. In either case generate a fresh proposal for the sprint you are planning now.

In Azure DevOps

Azure DevOps has no "no iteration", so Frankee returns an item to your team's backlog iteration, the one set in your Azure DevOps team settings, and the results list it under Returned to the backlog iteration. Adding an item sets its iteration to the sprint. If Frankee cannot read your team's backlog iteration, it does not guess: each item it would have returned is listed as not moved, with the reason, and everything else still moves.

Azure DevOps has no sprint state, so Frankee goes by the iteration's dates. An iteration whose dates include today has started, and Frankee will not push to it; one whose dates have passed is closed. An iteration with no dates set yet counts as open. Tasks are left alone: Frankee moves the user stories, product backlog items and bugs the plan is made of. Unlike Jira sub-tasks, Azure DevOps tasks do not follow their parent's iteration, so a returned item's tasks stay in the sprint and an added item's tasks stay where they were; move them by hand if you need to. If your process rules refuse the change for a work item, for example because a required field on it is empty, that item is listed as not moved with that reason.

Reading the proposal well

• Start with the headline. It is the finding most likely to change your plan. The ranked list under it, and the baseline details one click below, hold everything else.
• Then check 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 the scope observation before the items. If gaps are widespread, that is a conversation about scope, not eight conversations about tickets.
• Read "would question" and "could not assess" first. The retained items are the ones you already agreed on.
• Treat "Cannot Fully Assess" as a question, not a pass. It means Frankee could not check something. The badge tells you how many criteria, and the detail names them.
• 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.
• Cannot push to active sprint. The sprint was started in Jira after the plan was built, so Frankee moved nothing. Generate a fresh proposal.
• Create your next sprint first. Your tracker has no upcoming sprint for this team. Create it in Jira or Azure DevOps, then generate again. This is not an error, and it used no AI credits.
• Your tracker could not be reached. Frankee could not read your sprint, so it did not run anything. This is a different message from the one above: it means the connection failed, not that a sprint is missing. Try again shortly.
• 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.
• No readiness statuses. Your team has no active Definition of Ready, or every criterion on it is switched off. The plan says which, and neither blocks anything.
• Every item reads the same. Usually your Definition of Ready is stricter than the items are written, which is worth knowing. Open an item's gap detail to see exactly which criteria are involved.
• A fix would not post. Either the item changed in your tracker since Frankee read it, in which case generate a fresh proposal, or your tracker connection needs reconnecting. The message says which, and nothing was written either way.