Your first plan branch: a what-if sprint reshuffle

Time: 10 minutes. You'll need: workspace-member rights on a workspace, one project with a running sprint you can experiment on (a handful of tasks in the sprint is enough), and a rough idea of a change you want to try (a task to bump to urgent, another to move to the next sprint).

By the end you will have created a plan branch, staged a priority change and a sprint move on it, opened the Compare page to see the full before / after diff, merged the change in one click, and verified that main only moved at merge time.

What a plan branch is (and is not)

A plan branch is a named staging area for planning changes. It is not a copy of your plan; it is an overlay of the changes you stage. Creating one is instant. Nothing on main moves until you merge, and merge is drift-checked, so a teammate's newer edit on the same field is never silently overwritten.

Staging in v1 covers two knobs: a task's priority and its sprint membership. Every other edit (state, assignees, dates, description) still applies directly to main. Views (boards, lists, sprint list) keep showing main's values while you are on a branch; the Compare page is where staged changes surface.

1. Open a sprint

From the left rail, open a Project, then Sprints, and click into a sprint that has a few tasks in it. The sprint detail page loads with the sprint name in the header. Next to the name sits the branch picker, a branch icon reading Main. That is where you are: the live plan.

2. Open the branch picker and choose New branch

Click the branch picker. It opens a menu with Main at the top (the live plan), any open branches you already have, and a New branch entry at the bottom.

Click New branch.

3. Name and scope the branch

The Create branch dialog opens. Fill it in:

  • Name: something you and your teammates will recognise on the Compare page, for example Q3 Reshuffle.
  • Description (optional): a one-line note about what you are trying, for example Move PAR-1234 to next sprint, bump PAR-9876 to urgent.
  • Scope: pick This project only for a reshuffle bounded to the current project (a guest on the project can view it), or Workspace-wide for a cross-project reshuffle. Workspace-wide branches show a small workspace tag in the branch picker so you can tell the two apart.

Click Create branch. The picker turns amber with the branch name, and the branch banner appears at the top of the sprint page: "Viewing branch: Q3 Reshuffle. Changes here are staged, not live on main." The banner carries three actions on its right side: Compare, Merge, and Discard.

You are now on the branch. Your teammates are not; a branch is only "active" for the people who have selected it.

4. Stage a priority change

Click any task in the sprint list to open its detail panel. Change its priority from the priority dropdown (for example, from Medium to Urgent).

Instead of the usual save toast, a "Staged on branch" toast confirms the change. The priority chip on main is unchanged: if you switch back to Main from the branch picker, you will see the original priority. Come back to the branch and the panel shows the staged value.

5. Stage a sprint move

In the same detail panel, find the Sprint field. Remove the task from the current sprint (or add it to a different one).

Again the change stages. The sprint list under the banner keeps showing main's membership; the staged move is only visible on the Compare page in the next step.

6. Open Compare

Click Compare in the banner (or navigate to /{workspace}/plan-branches/{branch-id}/compare).

Each staged change appears as a row with:

  • The change type: Priority, Add to sprint, or Remove from sprint, and the task it touches.
  • On main: the value the branch recorded when you staged.
  • On branch: the value the branch wants to apply.
  • A Cherry-pick action to apply just that change now.

If a teammate edited the same field on main after you staged, the row is flagged Conflict: the branch's baseline no longer matches main. Merging will skip that row instead of overwriting their edit. If a change was cherry-picked earlier or landed in a previous merge, the row is flagged Already applied to main.

The page is live: if a teammate on the same branch stages another change while you are looking, it appears without a refresh.

7. Cherry-pick a single change (optional)

If one of the two changes is obviously right on its own, click Cherry-pick on that row. Ithura re-checks the baseline against main's current value and, if it still matches, applies the change in a single transaction. The row flips to Already applied to main, and the rest of the branch stays open for more thought.

If the baseline no longer matches, the cherry-pick reports a conflict and applies nothing. Nothing on main moves.

8. Merge the branch

Once the branch reflects the shape you actually want, click Merge all on the Compare page (or Merge on the banner).

Ithura opens a single transaction and re-checks every pending change against main's current value. Every change that still cleanly applies lands. Every change whose baseline no longer matches is reported back as a conflict, with a reason (drift if main moved, issue missing if the task was deleted).

Two toasts you might see:

  • Branch merged: every pending change landed.
  • Merged with N conflicts: some rows applied, some did not. The merged branch stays readable on the Compare page as a record; conflicted rows have to be redone on main by hand.

Either way the branch closes as merged. Merging and discarding are one-way in v1; a merged branch cannot be reopened.

9. Verify main only moved at merge

Open the branch picker (now back to Main after the merge closed the branch) and open the tasks you edited. The priority and sprint membership you staged are the current live values. Open the task's activity feed: the changes are attributed to you, with the same timestamp as the merge.

At no point before step 8 did main see the staged values. That is the whole idea.

Discard, if the reshuffle was a dead end

If, on Compare, the reshuffle turns out not to be worth shipping, click Discard instead of Merge. The branch closes without applying anything. Nothing on main ever saw the staged values. A discard cannot be undone.

Endpoints, for automation

The same operations are on the HTTP API:

GET  /workspaces/{slug}/plan-branches/
POST /workspaces/{slug}/plan-branches/
GET  /workspaces/{slug}/plan-branches/{id}/
POST /workspaces/{slug}/plan-branches/{id}/ops/
GET  /workspaces/{slug}/plan-branches/{id}/compare/
POST /workspaces/{slug}/plan-branches/{id}/merge/
POST /workspaces/{slug}/plan-branches/{id}/ops/{opID}/cherry-pick/
POST /workspaces/{slug}/plan-branches/{id}/discard/

Merge and cherry-pick return the applied op ids plus a conflicts list, each conflict with a reason (drift or issue missing).

What next

  • Plan branches: the full reference, including scope rules, role requirements, the exact fields the compare surface shows, and the current limits.
  • Monte Carlo forecasts: after a reshuffle merges, the sprint's P50 / P85 / P95 forecast band recomputes from the new scope, so the effect on the ship date is visible immediately.
  • Time Machine: complementary direction of travel. A plan branch stages future changes before they land; Time Machine restores a task to a prior day after changes landed.