Scenarios and commit
What this page is — The life of a scenario: seed it from the live tasks, shape it on a drag-and-drop board (by hand or with an AI suggestion), keep it in step with reality through drift and rebase, compare it with others, and commit it in one transaction. What it is for — Deciding a sprint plan with the team, then making it real in a single recorded step. The problem it solves — A plan built directly on the live board is impossible to compare with an alternative and impossible to take back. A scenario is cheap to make, cheap to discard, and its commit is previewed, validated and logged.
Route: /org/tasks/planning?tab=board (the Plan tab; also tab=live) · Permissions: View planning (read boards, drift, comparisons, history), Manage planning (move, assign, add time boxes, rebase, commit), the project milestone permission together with Manage planning (create, edit, move or delete a sprint or phase in the scenario, and commit those changes), Planning AI together with Manage planning (Suggest with AI)
Module: Planning · Entry points: header → New scenario · Plan tab · header or Plan toolbar → Suggest with AI · header → drift badge · Compare · Commit · Live tab
1. A scenario's states
A draft is editable. A committed scenario stays readable for comparison and clones; the page tells you it is read-only. Archive removes a scenario from the switcher — for a draft that discards its planned items, for a committed one the live tasks and the commit history keep everything.
2. Why you would use scenarios rather than the live board
- Nothing on the board notifies anyone until you commit.
- Two drafts of the same sprints can be compared side by side, including "with the new hire" versus "without".
- You see the moment reality diverges from the plan (drift) and choose how to reconcile.
- The commit shows every change it is about to make and refuses to make half of them.
3. Seeding a scenario — the fields
New scenario asks for:
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Unique among the project's non-archived scenarios |
| Time boxes | No | Open sprints and phases; ticking a phase ticks its sprints; completed boxes are not offered; Sprints without a phase listed last. Leave it empty to plan only the backlog — a project without sprints starts that way and creates its sprints inside the scenario |
| Include backlog | Default on | Tasks with no sprint yet appear in the Backlog column. At most 500 are seeded; a scenario needs a time box or the backlog |
| Backlog category | No | Seed only backlog tasks of this category |
| Backlog matching | No | Seed only backlog tasks whose title or key contains the text (Title or identifier contains…) |
| Include other open boxes | Default off | Also pulls tasks from open sprints not selected, so they can be moved in |
| Notes | No | What this scenario is trying out |
The scenario copies every open task of those boxes with its live placement, assignee and estimate — tasks already in a chosen sprint or phase are never filtered out, the filter and the 500 limit apply only to the backlog — and computes capacity for the roster plus any planned hires linked to the project. Parents with subtasks arrive as Group cards: read-only, their hours summed from the children.
The scenario remembers its backlog rule: drift later lists as New tasks since seeding only the new tasks that match it, and Add tasks on the Plan tab pulls in any other task you need. For example, on a project with 2,500 unplanned tasks, seed Payments with Backlog category Payments and Backlog matching checkout: the Backlog holds the 40 tasks that match instead of every task of the project.
Edit name, notes & time boxes (drafts only) re-seeds boxes you add and sends the items of boxes you remove to the Backlog. Clone as a new draft copies the planned values and re-seeds the baseline from today's live tasks.
4. The Plan tab — step by step
The Plan tab follows the project's hierarchy, Project → Phase → Sprints + Milestones. A task sits in exactly one time box — a sprint or a phase — or in the Backlog, and it can also contribute to a milestone. Sprints and phases are columns; milestones are dated checkpoints in a rail beside them, never columns. The tab was called Board before; its key in the address is still tab=board, so older links keep working.
Step 1 · Plan by sprints, phases, resource, size or category
The Plan by switch above the columns decides what a column is: Sprints, Phases, Resource, Size or Category. The first two lay the plan out in time; the other three regroup the same scenario to answer who, how big and what kind.
| Sprints (default) | Phases | |
|---|---|---|
| Columns | Backlog, then the chosen phase's sprints in date order — sprints only, never a phase column | Backlog, then every phase of the scenario in date order — phases only, never a sprint column |
| Tasks placed on the phase itself | At the top of the Backlog with a chip naming the phase; the Backlog header reads Also n on Phase 1 itself, not in a sprint. Drag one onto a sprint to move it in | In the phase's column, which also holds its sprints' tasks; the header note reads Includes n sprints |
| Cards | As usual | Each card in a rolled-up column carries a chip naming the sprint it sits in |
| Load and capacity | Per box | Load is the phase's own load plus its sprints' load; net capacity is the phase's own window |
| Picker | A phase picker chooses the phase; it opens on the phase running today when that phase has sprints, otherwise on the first group that has some. Sprints without a phase groups sprints with no parent phase. A phase with no sprints yet shows a note — Phase 1 has no sprints yet — create one in the Add sprint column — with a Plan by phases → link | None |
| Sprints whose phase is not in the scenario | Under their phase in the picker (Sprints without a phase when they have none) | Not shown: a note names them — Sprint 1 is not in any phase, so it is not shown here — with Show it →, which opens them in the Sprints view |
| Address | phase=<phase id> | by=phases |
When the scenario holds no phase and its sprints do not belong to different phases, there is nothing to pick: the Sprints view shows every sprint side by side.
The three value groupings keep the Backlog out and show every task of the scenario:
| Plan by | Columns | Dropping a card on a column |
|---|---|---|
| Resource | Unassigned, then each member and planned hire. Under the name: the skill the person is planned as on the Define tab (a hire reads Planned hire · skill); the header shows their planned hours against net capacity across the scenario (sprints, plus phases that have no sprints — a phase and its own sprints are never counted twice) | Plans the task on that person or hire |
| Size | Unsized (No size on the scale — drop on a size to estimate), then each size of the scale with its points and hours (range and default when the size has a range). A task sits in the size of its points, or — with no points — in the size its hours fall into | Gives the task that size's points and default hours |
| Category | No category, then each task category of the project | Sets the task's planned category |
Each is a change to the scenario only; the live task keeps its assignee, size and category until the commit, and the commit preview lists them like any other change. A category changed on the live task in the meantime shows as Re-categorised drift.
What a task is worth. When the project values its work (Settings → Money), each card carries a value under its title with a line saying how it was worked out — Fixed price, ₹4,000/day × 3d, 120 sqft × ₹450. Click the value to type a price; the card menu's Value block picks the basis and takes a quantity line's numbers. A value set in a scenario is a plan like any other: it reaches the task only at the commit. Column headers, resource rows, swimlanes and the Capacity tab add the values up, and a Rate-based value re-works itself whenever the task's days or the person on it change.
Look at one sprint — the In picker. In the Resource, Size and Category views an In picker sits next to the switch: All sprints & phases, or one sprint or phase. Pick one and the columns hold only that box's tasks (a phase includes its sprints); in the Resource view each person's header then compares their planned hours with their capacity in that box. For example, Plan by Resource, In Sprint 3: Arjun reads 38 / 30h in red, so drag one of his cards onto Unassigned or onto a colleague with room.
When to use which. Use Sprints for sprint planning: which task goes into Sprint 4 and who takes it. Use Phases to place work in the right phase before it is broken down into sprints, or to see whether a whole phase fits. For example, switch to Phases, drop 12 backlog tasks onto Phase 2, then switch to Sprints, pick Phase 2 and drag them from the top of the Backlog, where they carry a Phase 2 chip, into Sprint 4 and Sprint 5.
Step 1b · Group by — swimlanes
Group by, next to the switch, cuts every column into horizontal lanes by a second dimension: Resource, Size, Category, Sprint or Phase. A view never offers its own dimension, and the Sprints and Phases views offer only Resource, Size and Category: the Sprints view already shows one phase, and phase columns cut by sprint lanes would only fill a diagonal. None turns lanes off.
- A card sits in the cell where its column and its lane meet. Dropping it in another cell plans both values in one move, in the scenario only. For example, Plan by Sprints, Group by Resource: drag a card from Sprint 1 · Unassigned to Sprint 2 · Asha. It moves to Sprint 2 and is planned on Asha.
- Resource lanes show each person's planned hours against their capacity in every time-box cell, and in total on the lane title.
- Column headers stay on top and lane titles on the left. Click a lane title to fold the lane; the fold is remembered in this browser. Columns still collapse with «.
- Lanes are not offered on a phone. The Add sprint / Add phase column sits after the column headers and the Milestones rail stays on the right.
- The address keeps the choice:
lanes=resource.
Reading allocation per sprint is the main use: Plan by Resource, Group by Sprint shows one row per sprint and one column per person, with each person's load in that sprint.
Step 2 · Columns and cards
The Backlog column is followed by one column per time box, each showing its kind (Phase or Sprint), dates, a load-versus-net bar in state colour, points, task count, an Over/Under/OK chip, a % hires chip when work sits on planned hires (amber above 50%), an unassigned hours chip and the goal in italics. A box switched off in Goals shows Not in commit.
A parent with subtasks arrives as a read-only Group card showing Σ the hours and points of its subtasks; each subtask is its own card with a ↳ parent chip. Click Group · n (or a subtask's ↳ chip) to show only that parent and its subtasks in every column — the banner's Show all tasks (or Esc) removes the filter. A member of the family this view does not show — a subtask planned into another phase's sprint, or into a sprint that belongs to no phase — is named in the banner with where it sits and Show it →, so a parent never looks childless. While none of its subtasks has hours, the parent shows and counts its own estimate (8h own); once a subtask is estimated, the subtasks count instead. Use it to find and plan all of one story's subtasks.
A card shows the task key (click to open the task), title, effective hours and points, the assignee — a member avatar, a Hire chip, or Unassigned — and its chips: Group · N, Removed, the milestone it contributes to, and drift chips (Moved, Reassigned, Re-estimated, Re-categorised, Re-valued, Rescheduled, Completed, Deleted, New task, Time box changed). A dot marks a card changed in this scenario; a triangle means Task dates fall outside this time box; a bolt means Conflicts with a live change.
Step 3 · Move, assign, size
Drag the handle and drop the card anywhere on another column — its empty space, its header or one of its cards; the whole column lights up. Dropping on a card places it there; within a column it reorders. In the Phases view, dropping a card on a phase column places the task on the phase itself, out of whichever sprint it was in; reordering inside a phase column that holds sprints is not available. The card menu offers Assignee (Members, Planned hires, Unassigned), Points, Hours (blank means "use the live value"), Contributes to and Remove. The panel icon on a card opens the task's quick view — description, subtasks, comments, activity — beside the plan. Edits there are live task changes; when the panel closes, a draft scenario takes them onto the card wherever it still holds the value it was seeded with, while a value you changed in the scenario (a move, an assignee) stays and the live change shows as drift. Removing keeps the task itself untouched — it just stops being planned here, and moving it again adds it back. On a phone the board is a single list with a Move to… select per card.
Step 4 · Add or create a sprint or phase
The last column is Add sprint in the Sprints view (for the phase in the picker) and Add phase in the Phases view. It appears on a draft scenario you can change.
- On the Roadmap, not in this scenario lists the sprints of that phase (or the project's phases) that exist but are not planned here, each with its dates and open task count. Add brings one into the scenario; adding a phase brings its sprints along.
- Create sprint / Create phase opens a dialog with Title, Start and End already filled in: the next number (Sprint 3, Phase 4) and dates starting the day after the last sprint (or phase), with the same length. A first sprint starts on its phase's start date and runs 14 days; a first phase starts today and runs 30 days. A sprint is created under the phase in the picker — including a phase created in this scenario — and the dialog warns These dates run outside the phase when they do.
A new sprint or phase lives only in this scenario. Its column carries a blue New chip, you can plan tasks and capacity into it straight away, and the toast reads Sprint added to this scenario — … goes on the Roadmap when you commit. Nobody else sees it — not the Roadmap, not other scenarios, not the task pickers — until the scenario is committed; then it is written to the Roadmap together with the tasks planned into it.
Creating needs the project milestone permission (Manage milestones); without it there is no Create button, only Add, and when nothing is left to add the column says Creating a sprint needs the Manage milestones permission. The date rule of the project applies as on the Roadmap: in warn mode the box is added with a warning in the toast; in block mode a box outside its phase is refused and the dialog stays open (see Phases, sprints and milestones).
Example: Phase 2 needs one more sprint. With Phase 2 in the picker, press Create sprint; the dialog offers Sprint 3 · 1 Oct – 14 Oct. Save, and Sprint 3 · New appears as a column ready to take tasks, while the Roadmap still shows two sprints.
Step 5 · Edit, move or delete a sprint or phase
Each sprint or phase column has a ⋯ menu. Every change you make there is kept in the scenario, like a task move, and reaches the Roadmap only when you commit — the menu says Changes wait in this scenario. The Roadmap changes when you commit.
| Menu item | What it does in the scenario | On commit |
|---|---|---|
| Edit title & dates | The column shows the new title and dates with an orange Edited chip; hover it to see the Roadmap's current version | The Roadmap box takes the new title and dates |
| Move into a phase… / Move to another phase… (sprints) | Lists the scenario's phases, including new ones, then the Roadmap's other phases; Leave it without a phase takes it out | The sprint's phase changes on the Roadmap |
| Undo changes (use the Roadmap's) | Shown on an Edited box; puts back the Roadmap's title, dates and phase | Nothing is written for that box |
| Remove from this scenario | The box leaves this scenario only; its tasks go to the Backlog | Nothing — the Roadmap keeps the box |
| Delete on commit | After a confirmation, the column leaves the board and its tasks go to the Backlog. The box is listed in a strip above the board — Deleted on commit: Sprint 2 Restore — They stay on the Roadmap until you commit. | The box is deleted from the Roadmap; a deleted phase's sprints stay, without a phase |
| Discard this sprint / phase (a box created in this scenario) | The box and its capacity are gone at once; its tasks go to the Backlog | Nothing — it never reached the Roadmap |
Restore puts a box you deleted back on the board. Its tasks stay in the Backlog; move them back if you still want them there. Changing the dates of a box recomputes its capacity; your overrides are kept.
The menu items that change a box need the milestone permission as well as Manage planning; without it only Remove from this scenario is offered. If someone changes the same box on the Roadmap after you edited it here, the commit preview warns before overwriting their change (see Commit).
Step 6 · The Milestones rail and readiness
The right-hand rail lists the project's milestones with their date, parent phase, status and contributing count. Drop a card on one to set what it contributes to. Press the count to expand the entry: each contributing task is listed with the sprint or phase it sits in and when that box ends, Not in a sprint or phase, or Done.
Each milestone carries a readiness chip, worked out from this scenario:
| Chip | Meaning |
|---|---|
| On track | Every open contributing task sits in a sprint or phase ending on or before the milestone date |
| Late · date | The latest of those boxes ends after the milestone date; the chip shows that end date |
| n unplanned | n open contributing tasks are not in any sprint or phase |
| No tasks | Nothing contributes to the milestone yet |
| Done | All contributing tasks are done |
Check the chips before committing. For example, Portal Launch shows Late · 14 Nov: its tasks sit in Sprint 6, which ends after the launch date, so move them into Sprint 5 and the chip turns On track.
Step 7 · Find, filter and add tasks
The toolbar above the columns holds:
- Find a task… — title or key, in every column.
- Assignee — one person, a planned hire or Unassigned.
- Card fields — up to three extra lines on every card: Priority, Due, Start, Category, Contributes to, Story points, Remaining, or any Jira field captured on the project's tasks (the picker shows how many tasks carry each). Saved for you on this project, so it follows you to another browser; Clear all removes them. For example, tick Due and the Jira field Phase and every card reads Due: 30 Sep 2026 and Phase: Phase-1.
- Filters — opens a row with Category, Status, Priority and Milestone selects and four toggles: Unestimated (no hours and no points), Unassigned, Drifted (tasks whose live values changed, with the drift count) and Warnings (a date-boundary warning or a conflict). The button reads Filters · n while n of them are on.
- Clear once any filter is on.
- + Add task (top of the Backlog) — type a title and press Enter to add a task that exists only in this scenario. Its card reads New task and New — created on commit; size, assign and place it like any other card. The commit lists it under New tasks and creates it in Tasks with its sprint, assignee, estimate and category. Removing it before commit discards it. Needs the Create task permission.
- Add tasks — searches the project's live tasks by title or key (Title or identifier…) and adds the ones you pick to the Backlog column. Use it for a task that was outside the scenario's backlog rule or the 500 limit. Nothing changes on the task itself until you commit.
To estimate on the board, click the hours on a card, type a number and press Enter (empty returns to the size's default or the live value). The card shows the new hours at once while the draft saves; if the save fails, the previous value comes back with a message. Esc closes the box without saving. With hour ranges on the sizes the card moves to the size whose range holds the hours. An open task whose remaining hours are 0 counts its estimate, not 0h. A task key opens the task in a new tab.
A filter narrows every column, and each column's header still says how many tasks it holds. A long column shows 60 cards at a time with Show more at the bottom, so a backlog of several hundred tasks stays quick to drag in.
Every move, edit and capacity change is saved to the draft at once. The scenario bar shows Saving… while a change is on its way and Saved HH:MM afterwards; Not saved — retry the last change means the last change did not reach the server. On a draft you may change, the scenario bar holds Suggest with AI — see the next section.
Hold Alt (or Shift) and turn the mouse wheel to scroll the board sideways. A card can be dropped on a collapsed column's thin bar without expanding it.
5. Suggest with AI
Suggest with AI asks the AI to fill the scenario for you: which sprint each unplanned task should go into and who should take it, without pushing anyone past a capacity limit you choose. It is a proposal. Nothing changes until you tick the moves you want and press Apply, and even then only the draft scenario changes — the live tasks are untouched until you commit.
Where the button is
- In the page header, between Compare and Commit (on a phone it reads Suggest).
- At the right-hand end of the Plan toolbar.
- From a link that opens the page with the suggestion drawer already open (see Planning workspace → deep links).
The button appears only when all of these hold: a draft scenario is selected, you have Manage planning, and you have Planning AI. On a committed scenario the button is absent; if the drawer is opened anyway it says Only a draft scenario can take suggestions. Clone this scenario to plan from it.
Step 1 · Choose the options
| Option | Control | Default | What it does |
|---|---|---|---|
| Strategy | Three cards, pick one | Balanced | Sets the most hours the AI may plan on one person in one time box — see the table below |
| Time boxes | Chips, one per sprint or phase of the scenario; tap to toggle | None ticked = All time boxes in this scenario | Limits where tasks may be placed. The hint changes to N selected |
| Include tasks that already have a sprint/assignee | Tick box | Off | Off: only tasks without a sprint or without an assignee are considered. On: the AI may also move or reassign fully planned tasks. |
| Guidance (optional) | Text area, up to 2,000 characters with a live counter | Empty | Plain-language instructions, e.g. "Keep payments work together in Sprint 4" or "Priya is new — give her smaller tasks" |
The three strategies, with the limit the platform enforces on every proposed move (net capacity is the per-person, per-time-box figure from the Capacity tab):
| Strategy | Card text | Limit per person per time box | Tasks with no estimate |
|---|---|---|---|
| Balanced | Fill each sprint close to capacity, keeping a small buffer. | 90% of net capacity | Left out |
| Aggressive | Pack as much as fits — up to full capacity, no buffer. | The project's overload ratio × net capacity (1.2 by default, set in Risk Radar settings) | May be placed |
| Conservative | Leave generous slack for interruptions and unknowns. | 75% of net capacity | Left out |
Step 2 · Generate
Press Generate. The drawer shows Planning your sprints… while it works. Which tasks the AI is shown:
- Open tasks of the scenario that sit in the Backlog or in one of the chosen time boxes. Group cards and cards you removed are never moved.
- With the include tick box off, only those still missing a sprint among the chosen boxes, or missing an assignee.
- At most 150 tasks, highest priority first, then earliest due date. The rest are listed under Left in the backlog with Not considered: only the first 150 items by priority and due date go to the AI.
The AI also reads each time box's dates, goal, net capacity and current load; each member's skills and levels; the planned hires linked to the project and their availability windows; each task's estimate, points, priority, dates, predecessors and tags; and the project's open milestones (so it can also set what a task contributes to).
Step 3 · Read the result
| Section | What it shows |
|---|---|
| Rationale | The AI's explanation of the plan, with a chip naming the strategy and a Cached chip when the result was served from a stored run |
| Capacity after applying | One row per time box: planned hours / net hours, a state chip (Over, Under, OK, No capacity) and a load bar — as they would be if you applied every proposed move. Expand a row to see each person; planned hires are marked (hire) |
| Proposed moves | A table with a tick box per move, a select-all box, and the columns Task (key and title), Sprint, Assignee and Reason. Every move starts ticked; the chip reads ticked / total |
| Left in the backlog | Tasks the suggestion did not place, each with the reason — for example Placing it would take Priya past the balanced limit in Sprint 4 (42.5h of 38.9h)., No estimate yet: size it before planning it with the conservative strategy. or Not placed by the suggestion. |
| Not applied | Moves the AI proposed that the server refused, each with its reason: the task was not one it could move, the sprint was outside your selection, the person or planned hire was not eligible, or an id could not be read. Tasks refused for the strategy limit or a missing estimate appear under Left in the backlog instead, with the reason |
Before the result reaches you, every proposal is checked. A move is discarded when it names a task that was not offered, a time box outside your selection, or a person who is not an active member of the project or an active planned hire available in that time box. A move that would exceed the strategy limit, or that lands on someone with no net capacity in that box, is turned into a Left in the backlog entry with the reason. So the table only ever holds moves the platform will accept.
Two things to read carefully in the table:
- Assignee shows who the task will be planned on. When the AI proposes no person, the move keeps whoever is already planned on the task — applying a suggestion never unassigns anyone.
- Sprint is the time box the task will sit in; a move that only changes the assignee repeats the task's current box.
If the table reads No moves proposed — the scenario already fits, or nothing else fits the capacity., try Aggressive, widen the time boxes, or size the unestimated tasks.
Step 4 · Apply, or regenerate
- Apply N moves writes the ticked moves to the draft scenario in one step — exactly as if you had dragged and edited those cards yourself. Each changed card gets the changed in this scenario dot, the columns' load bars update, the toast reads Suggestion applied — N moves applied to the scenario name, and the drawer closes. Untick everything and the button is disabled.
- Regenerate ignores the stored result and asks the AI again with the current options. It spends credits again.
Apply never commits. Review the board, adjust by hand, then use Commit as usual — the commit preview still checks every rule.
Cached results and credits
The footer reads Uses AI credits. Cached results are free. A result is stored per scenario and reused, without spending credits, when you press Generate again with the same strategy, time boxes, include setting and guidance and the scenario's tasks, capacity and loads have not changed. Any change to those — a card moved, a capacity cell overridden, a word of guidance — produces a fresh run. A cached result is re-checked against the board as it is now before it is shown.
A fresh run costs about 600 credits, with a ceiling of 2,400 for a very large scenario.
When it does not work
| Message in the drawer | Cause |
|---|---|
| Not enough AI credits to suggest a plan. Top up credits and try again. | The organisation's credit balance is below what the run needs |
| The AI service is unavailable right now. Try again in a few minutes. | The AI service, or the suggestion utility, is switched off or unreachable |
| This scenario is no longer a draft, so suggestions cannot be applied. Clone it to keep planning. | Someone committed or archived the scenario while the drawer was open |
| You do not have the … permission. | Your role lacks Planning AI — the same message appears when AI is switched off for the organisation |
6. Drift and rebase
While you plan, the live tasks keep moving — and so do prices. A task whose value, basis, quantity or unit rate changed in Tasks reads Re-valued, and so does one whose day rate moved: a rate changes without the task row ever being touched, so it is checked on its own.
While you plan, the live tasks keep moving. The header badge reads No drift or N drift; the Drift against live drawer groups changed tasks by kind with each field's base → live value, lists changed time boxes and New tasks since seeding. Two ways to reconcile:
| Button | Untouched items | Items you changed | New / gone tasks |
|---|---|---|---|
| Rebase · adopt live | Follow live | Take the live placement, assignee and estimate; your planned changes on them are dropped | New tasks join the Backlog; deleted or completed tasks are removed |
| Rebase · keep planned | Follow live | Keep your planned values and show a conflict bolt | Same |
7. Commit
Step 1 · The analysis
Commit first opens a full-screen analysis of the plan — nothing is written here. Tiles show utilisation, time boxes over capacity, the tasks and value planned, unassigned load and the number of changes; charts show capacity against planned load per sprint, utilisation per person, a person × sprint heat map (green 60–100%, amber under 60%, red over 100%), value per sprint, where the effort or money goes by category, this plan against the last commit, and what the commit changes. Continue to commit opens the preview below; Esc goes back to the plan.
Step 2 · Review and confirm
The preview: Writes the planned placements, assignees, estimates, goals and capacity to the live project. One transaction — all or nothing. It shows counters (Tasks changed, Moved, Reassigned, Re-estimated, Hires assigned, Time boxes, Net capacity, Committed load — plus Re-valued and Committed value when the project values its work), then:
| Section | What it holds | What to do |
|---|---|---|
| Blocking | Violations — the commit will not run | Fix the task or scenario, reopen the preview |
| Warnings | Findings you may accept | Tick I understand — commit anyway, then Commit |
| Tasks planned on hires | Tasks that stay unassigned with a planned-hire marker | Nothing; replace the hire later |
| Sprints & phases | Every sprint or phase this scenario creates, changes or deletes: Create (dates and phase), Change (only what changed — was old title, old → new dates, into a phase or out of its phase), Delete | Review — these are written to the Roadmap first, in the same step as the task changes |
| Task changes | Field-by-field diffs, each task with a tick — all ticked to start with, Untick all / Tick all above | Untick what should wait. A commit that leaves work out keeps the scenario a draft, so the rest can be committed later |
| Capacity changes · Goal changes | What the committed plan will record | Review |
| Code | Text | Kind |
|---|---|---|
timebox_invalid | Time box is not a plannable sprint or phase (completed, wrong type or another project). | Blocking |
target_must_be_milestone | The contributes-to target must be a Milestone. | Blocking |
assignee_not_member | The assignee is not an active member of this project. | Blocking (a warning while still on the board) |
task_outside_timebox | The task's dates fall outside its time box. | Blocking in block mode, warning in warn mode |
scenario_not_draft | Only a draft scenario can be committed. | Blocking |
resource_overloaded · resource_underloaded | A person is planned above their capacity / below the underload ratio. | Warning |
virtual_share_high | More than half of a time box is planned on hires that do not exist yet. | Warning |
goal_missing | A time box has no goal. | Warning |
drift_present | Live tasks have changed since this scenario was seeded. | Warning — or a block when Commit requires no drift is on |
roadmap_permission_required | Creating, editing or deleting sprints and phases needs the Manage milestones permission. | Blocking |
timebox_gone | A sprint or phase edited in this scenario was deleted from the Roadmap meanwhile. | Blocking — undo the change or remove the box |
timebox_edit_conflict | The box changed on the Roadmap after it was edited here; committing overwrites that change. | Warning |
sprint_outside_phase · phase_shrinks_below_children · sprint_overlap | A sprint or phase created or edited here breaks the Roadmap's date rules. | Warning — the first two block in block mode |
parent_must_be_phase · parent_deleted · phase_cannot_have_parent | A sprint sits under something that is not a phase, or under a phase this scenario deletes. | Blocking |
Three messages can interrupt a commit: The scenario changed since this preview was built. Refreshed — review and commit again. · A task changed while committing. Nothing was written — refreshed, review and commit again. · Live tasks changed since this scenario was seeded. Rebase the scenario, then commit.
What a commit writes, in one transaction: first the sprints and phases the scenario creates or edits (a new box keeps the id it had in the scenario, so the tasks planned into it land in it); then for every changed task its time box, contribution, assignee or planned-hire marker, story points, estimated and remaining hours and estimate source; for every included box the committed plan (goal, success criteria, focus factor, net capacity, committed hours and points); the committed per-person capacity; a commit record with every diff and the acknowledged warnings; then the deletions of sprints and phases; the scenario becomes committed and phase rollups are refreshed. The Roadmap sends its usual milestone created / updated / deleted webhooks for the box changes. Afterwards the reassigned members get the normal assignment notification, project managers and leads receive Plan committed, and every other draft of the project starts showing drift.
8. Compare, Live and history
Compare opens Compare plans, which takes two or three columns — scenarios and Live plan (committed plans plus live tasks) — and shows Per time box (net, load, ratio, state, tasks, points, hire share), Per person, and Where each task sits with an Only differences link (Show all tasks turns it back).
The Live tab renders the committed plan read-only, one level at a time like the Plan tab — Plan by Sprints (the sprints of one phase, with the phase picker) or Phases (each phase holding its sprints' work) — with the same columns (done tasks included, so counts are meaningful), and the Commit history. Opening a commit shows its counters, Warnings acknowledged, Task changes, Goals written and Capacity written.
9. Worked example
A scrum master seeds Sprint 12 plan on Monday, covering Sprints 12 and 13 with the backlog included. Thirty backlog tasks have no sprint. She opens Suggest with AI, keeps Balanced, ticks only Sprint 12 and Sprint 13, and types the guidance "Checkout tasks stay together; Priya is new — smaller tasks". The result proposes 22 moves; Capacity after applying shows Sprint 12 at 88% and Sprint 13 at 84%. Six tasks are Left in the backlog — four have no estimate, two would take a senior developer past the 90% limit. One move shows — under Assignee for a task Tom already owns, so she unticks it and applies the other 21. The board updates; she drags one checkout task back beside its siblings by hand. By Wednesday a developer has closed two tasks and a lead re-estimated another: the badge reads 3 drift. She rebases with Rebase · keep planned — her moves stay, the two completed tasks leave the board. Commit preview shows one Blocking item: a task she assigned to a contractor who left the project (assignee_not_member). She reassigns it, reopens the preview, ticks I understand — commit anyway for one resource_overloaded warning, and commits. The toast reads Plan committed — 14 tasks updated across 1 time box, the Live tab opens, and the sibling draft Sprint 12 stretch now shows drift.
10. The admin contract
- Committing is the only write to real tasks from Planning; it requires Manage planning, and the per-field task permissions (assignee, estimate) are not consulted on the way — grant it as you would grant bulk editing.
- Commit requires no drift (Project settings → Planning) decides whether
drift_presentblocks or merely warns. - The Plan committed notification goes to the project's managers and leads by bell and email.
- Suggest with AI needs Planning AI and Manage planning on the role, AI enabled for the organisation, credits on the organisation, and the platform's Planning Scenario Suggestion AI utility switched on by your platform operator. Without the utility the drawer reports that the AI service is unavailable.
- The Aggressive limit follows the project's overload ratio in Project settings → Risk Radar; the other two limits are fixed.
11. Don't confuse this with…
- Bulk actions — immediate multi-task edits on the live list; no preview, no capacity.
- Planning assistants → Plan sprint — an AI proposal for one sprint, started from the Roadmap and applied straight to the live tasks. Suggest with AI works across every time box of a scenario, respects a strategy limit per person, can plan onto hires, and writes only to the draft.
- Jira sync — moves tasks between systems, not between sprints.
12. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Cards will not drag | Committed scenario, or no Manage planning | Clone; ask for the permission |
| A card cannot be reordered inside a phase column | In the Phases view a phase column that holds sprints is a roll-up | Switch to Sprints to order tasks inside a sprint |
| A task dropped on a phase column left its sprint | In the Phases view a drop on a phase places the task on the phase itself | Switch to Sprints and drag it into the sprint |
| The Plan tab shows other sprints than expected | The Sprints view shows one phase at a time | Pick the phase in the phase picker, or Sprints without a phase |
| No Create sprint button in the add column | You lack the project milestone permission | Ask for Manage milestones, or Add a sprint that already exists |
| A sprint created here is not on the Roadmap | It waits in the scenario until the commit | Commit the scenario |
| A column vanished after Delete on commit | Deleted boxes leave the board until the commit | Press Restore in the Deleted on commit strip |
| The column menu offers only Remove from this scenario | You lack the milestone permission | Ask for Manage milestones |
Commit blocked by roadmap_permission_required | The scenario changes sprints or phases and you lack the milestone permission | Ask for it, or undo those box changes |
| The Backlog holds 500 tasks but the project has more | A scenario seeds at most 500 backlog tasks | Seed with a Backlog category or Backlog matching, or use Add tasks |
| A column ends with Show more | Columns show 60 cards at a time | Press it, or narrow the view with a filter |
| No add column at all | The scenario is committed, or you lack Manage planning | Select or clone a draft |
| A milestone reads n unplanned | Contributing tasks sit in the Backlog | Drag them into a sprint or phase |
| A card is faded and says Removed | You removed it from the scenario | Move it into a column to restore |
| Commit button missing | Not a draft, or no Manage planning | Select a draft |
| "Drift must be zero to commit" | Project setting is on and drift exists | Rebase, then commit |
| Commit says the preview is stale every time | Someone else is editing the same draft | Coordinate; refresh and retry |
| Suggest with AI is missing | The scenario is committed, or you lack Planning AI or Manage planning | Select or clone a draft; ask for the permissions |
| The suggestion ignores tasks you expected | They already have a sprint and an assignee and the include tick box is off, or they are beyond the first 150 | Tick Include tasks that already have a sprint/assignee; narrow the time boxes |
| Many tasks under Left in the backlog with No estimate yet | Balanced and Conservative never place unestimated tasks | Size them, or use Aggressive |
| Generate returns the same result instantly | A cached result for the same inputs was reused | Change the options or press Regenerate (spends credits) |
| A move is listed under Not applied | The server refused it; the reason says why (for example the person is not an active member of the project) | Fix the cause — add the member, widen the time boxes — and Regenerate |
| Compare shows No time boxes in common | The picked scenarios plan different sprints | Pick scenarios of the same boxes, or include Live plan |