The planning conversation always ends the same way. Someone says what if we moved PAR-1234 to next sprint and bumped PAR-9876 to urgent. Everyone stares at the sprint page. Nobody wants to actually drag the tasks around, because the moment you do, the whole team sees a half-considered reshuffle as if it were the plan. So the reshuffle stays in Slack, gets forgotten, and the sprint runs against the old shape.
Plan branches fix that shape. A branch is a named staging area for planning changes: switch to it from the branch picker on the sprint page, then change task priorities and move tasks in and out of sprints as usual. Every edit records on the branch instead of touching the live plan. An amber banner makes the mode unmistakable. Open Compare to see the full before / after diff, then merge in one click, cherry-pick single rows, or discard the whole experiment.
The picker in the sprint header turns amber with the branch name. Every edit made while the banner is up records on the branch instead of touching the live plan.
Why an overlay, not a copy
Copying the plan would mean copying every task, every field, every join. It would also mean a branch instantly starts drifting from main the moment anyone edits anything on either side. Merging that back is a hairball.
A branch here stores only the changes you stage. The rest of the workspace stays the workspace. When you look at a list or a board on a branch, you are still looking at main; the Compare page is where staged changes surface. Creating a branch is instant, and the branch cost is proportional to the edits, not to the size of the plan.
Drift-checked, transactional merge
Every staged change records the value it saw at staging time as its baseline. That baseline is what makes safe merges possible.
Merge re-checks every change against main's current value in a single transaction. Everything that still cleanly applies lands. Everything else is reported back as a conflict, with a reason (drift or issue missing), instead of silently overwriting a teammate's newer edit.
Cherry-pick applies one row now with the same baseline check. Handy when the priority bump on PAR-9876 is obviously right, but the sprint move on PAR-1234 needs another conversation. The row flips to Already applied to main and the branch stays open for the rest.
Discard drops the branch. Nothing lands on main. The Slack conversation returns to talking.
What is staged today
- Task priority. Changing the priority dropdown while a branch is active records a
set_priorityop on the branch instead of updating the task. - Sprint membership. Adding a task to a sprint records
add_to_cycle; removing recordsremove_from_cycle.
Every other edit (state, assignees, dates, description) still applies directly to main. That is v1's line: cover the two knobs the reshuffle conversation actually turns, ship the drift-checked merge machinery underneath, then broaden the staged field set from there.
Live to the team on the branch
A branch is a shared object. When a teammate on the same branch stages another change, cherry-picks a row, merges, or discards, your banner and Compare page update on their own, the same envelope the sprint page uses. No refresh, no polling loop.
Which branch you have selected is remembered per workspace in your own browser, so navigating around does not lose the branch, and other people are not affected by your choice.
What is not in v1
- Overlaid views. Boards, lists, and sprint views keep showing main's values while you are on a branch; the Compare page is the only place staged changes surface until you merge. A future v2 will paint staged changes into the sprint view itself, marked as staged.
- The picker lives on the sprint page. You can stage from the task detail panel from anywhere, but the branch picker itself sits on the sprint detail header for now.
- One active branch at a time per workspace, per browser. Switching workspaces switches to that workspace's own remembered branch.
Related
- docs/features/plan-branches, the full reference: scope rules, roles, the endpoint surface, and the conflict semantics.
- docs/tutorials/plan-branches-first-what-if, a ten-minute walkthrough: create a branch, stage a priority and a sprint move, compare, merge.
- docs/features/forecasts. After a reshuffle merges, the sprint's Monte Carlo forecast band recomputes from the new scope.