How to plan sprints and run Agile delivery in Plane

Sprint planning breaks down in two directions. If every blocker, priority shift, or urgent request reopens the plan, the sprint stops creating focus. If the original scope stays fixed regardless of what happens during delivery, the plan stops reflecting the work. Agile delivery has to hold both together: a clear commitment, with room to respond when execution changes what the team knows.

In Plane, sprints run as Cycles. This guide follows the full delivery loop: choosing ready work, planning the cycle around an objective, using estimates and dependencies to shape the commitment, tracking delivery, responding when the plan changes, and carrying what the team learns into the next cycle.

1. Start from work that is ready to plan

Sprint planning should not begin by reopening the entire backlog. When the team is still deciding what is ready, planning and grooming become the same exercise.

To follow the workflow, we’ll use Meridian, a product company with a communication tool preparing a release of a new feature. The feature lets users write a message now and choose when it should be sent, with work spanning the compose UI, backend scheduling, notifications, and timezone handling. The team has two weeks to bring that work together in Sprint 12.

Start planning with Custom State Groups

Meridian starts with work that has already been through backlog grooming and is ready for consideration. The team uses the Later → Next → Now state group model: Later holds work further out, Next narrows what is coming up, and Now contains the work ready to enter planning.

For the scheduled messages release, Now contains six work items, including the compose UI, backend scheduler, notification handling, and timezone handling. Priority and time Estimates sit alongside each item, giving the team the relevant planning inputs as it decides what belongs in Sprint 12.

Backlog grooming gets the work to Now and sprint planning decides what the team commits to.

2. Build the sprint in a Cycle

The ready pool gives the team its candidates. Next, decide which ones belong in the commitment for the next two weeks.

Start the Cycle with a clear objective

Start with what Sprint 12 is for: get scheduled messages ready for release. That objective gives the team a basis for choosing from the ready pool, because ready does not automatically mean included.

All six work items are legitimate candidates, but they do not contribute equally to that objective. The compose UI, backend scheduler, and notification handling are directly tied to getting the feature ready for release. Less important work can remain in Now for a later Cycle. The team can keep the objective in the Cycle description as a reference during delivery.

The same applies when something essential is missing from the ready pool. If the work the release depends on is not ready yet, that becomes a constraint on what the team can commit to, rather than a reason to bring under-defined work into the Cycle.

Use priority and Time estimates to shape the Cycle scope

Create Sprint 12 as a two-week Cycle and set its start and due dates. The team can then add the work it is considering from Now.

Priority helps distinguish which work matters most to the release. Meridian also uses Time estimates to record the expected delivery time for individual work items. Those estimates give the team another input as it considers what it can take on across the two weeks, without treating them as a fixed capacity budget.

The work recorded in Plane is only part of that decision. Team availability, on-call responsibilities, holidays, and known interruptions can all affect what is reasonable to commit to. The team weighs those conditions alongside the work before settling on the scope for Sprint 12.

Check dependencies before committing

The work also has to fit together.

For scheduled messages, Notification handling is blocked by the backend scheduler. The work item relation makes that dependency visible before the team commits to both pieces of work.

That dependency becomes part of the planning decision. The team needs to consider whether the backend scheduler is likely to land in time for notification handling to follow, and what happens if it does not.

By the end of planning, Sprint 12 has a defined objective, a two-week boundary, and a set of ready work the team is prepared to commit to.

3. Run the Cycle and adapt as you go

Planning sets the commitment for Sprint 12. Agile delivery starts with what happens next: the team works against that plan while responding to what it learns along the way.

Some changes affect how the work gets done while others are significant enough to make the team reconsider what it committed to.

Move work through states as delivery unfolds

Work moves through its states as the team progresses. Notification handling remains blocked by the backend scheduler, so other available work can continue while that dependency is unresolved.

Other assumptions can change too. A priority may shift as the release gets closer. A Time estimate may need to be revised once the team understands the work better. The team can respond to either without reopening the Cycle scope.

Plane keeps the work and its changes together as the Cycle runs, so the team can respond to what is happening without treating every change as a new planning exercise.

Use Plane Agents to investigate urgent work

Midway through Sprint 12, the team discovers that some scheduled messages are being sent twice. The regression is urgent enough to compete with the work already planned, so Scheduled messages sending twice enters the Cycle as urgent work.

The team brings a configured Plane Agent onto the investigation. Working within its instructions and scope, the Agent uses the context available to it in Plane to investigate the urgent work and return its findings for review.

The investigation stays attached to the delivery workflow instead of becoming a separate AI conversation. In this workflow, the Agent's responsibility ends with the investigation. Teams that want to take this further can also build agentic workflows around the work in Plane.

Revisit Cycle scope when the commitment changes

The team now has to decide what the urgent issue means for Sprint 12.

If the regression needs to ship immediately, the team may change the sequence of work, move something else out of the Cycle, or adjust the scope another way. It may also decide that the existing commitment can still hold.

The important distinction is between changing execution and changing the commitment. A blocker, revised estimate, or shifted priority can often be handled within the existing scope. Urgent work can justify reopening that scope, but it does not do so automatically.

4. Inspect progress while there is still time to respond

Sprint 12 is still running, so progress is useful for more than reporting where the team stands. It shows where delivery is drifting from the plan while there is still time to respond.

For Meridian, this is how Agile delivery stays responsive.

Track delivery with Cycle progress

Cycle progress shows how the sprint is moving, including completed and pending work and the time remaining.

That gives the team a common starting point for standups and reviews. Instead of reconstructing status from individual updates, it can focus the discussion on the work that needs attention.

Read the trajectory with burn-down

The overview Burn-down shows how actual progress is tracking against the Cycle's trajectory.

For Sprint 12, Meridian tracks this by work item count. That is separate from the Time estimates used during planning. Time estimates describe the expected delivery time of individual work items; the progress chart follows how many work items move to completion during the Cycle.

Investigate delays in the Cycle

Around day six, Sprint 12 is trailing while the backend scheduler and its dependent work remain open.

That gives the team a reason to inspect what is holding delivery back. The response might be to clear the blocker, change sequencing or priority, revisit scope, or leave the plan unchanged.

A progress signal is useful because it directs attention. It does not prescribe the response.

5. Decide what happens to unfinished work

A sprint can end with planned work still open. In Sprint 12, Timezone handling for scheduled sends remains unfinished.

Move unfinished work when you end a Cycle

When Sprint 12 ends, the team can move incomplete work into an active or upcoming Cycle. For projects using Auto-schedule cycles, Auto-rollover work items can move incomplete work into the next Cycle automatically. For Meridian, timezone handling moves into Sprint 13.

That handles where the work goes next. It does not explain why the work remained unfinished.

Review the Cycle before carrying the work forward

Before planning the item again, the team can look back at Sprint 12: what completed, what remained open, where dependencies affected delivery, and what unplanned work entered during the Cycle.

Unfinished work can have very different causes. The original scope may have been too broad. A dependency may have held the work up. Priorities may have shifted. Unplanned work may have changed the conditions of the Cycle.

The fact that an item carried forward does not tell the team which explanation is correct.

Ask why work was carried forward before planning it again

Carryover is evidence rather than a verdict. It does not automatically mean the team overcommitted, and it does not prove that an estimate was wrong.

Before putting the same work into another sprint, understand what prevented it from finishing and whether anything needs to change. Otherwise, moving it into Sprint 13 risks carrying the same problem forward with it.

6. Use one Cycle to inform the next

When Meridian planned Sprint 12, it knew what it wanted to achieve and what it was prepared to commit to. Delivery added information the team did not have at the start.

By the end of the Cycle, it has a clearer record of what completed, what remained open, where dependencies affected delivery, and what unplanned work entered along the way. That record gives the next planning session a better starting point.

Use a Plane Agent to prepare the Cycle review

A configured review Agent can help assemble relevant work-item context before the next planning session, within the projects and context available to it.

For Sprint 12, the review can bring together the work that completed, what carried forward, dependencies that affected delivery, and the urgent work that entered during the Cycle.

The team can then review that context alongside the Cycle record before planning Sprint 13.

Keep the Cycle review in Wiki

Some of what the team learns from Sprint 12 should remain useful after the Cycle itself is over.

Meridian keeps the review in Wiki, capturing the important delivery context, what carried forward, and the decisions or follow-ups that should inform future planning. Instead of reconstructing why an item moved or why scope changed several Cycles later, the team has a durable review record to return to.

This keeps the review close to execution without asking the Cycle itself to carry every piece of reasoning. More broadly, that is the value of connecting project management and knowledge management: the work records what happened, while the knowledge layer preserves the context teams will need again.

Bring carryover and dependencies into the next Cycle

Planning now returns to the same Now pool it started from, but the team knows more than it did two weeks earlier.

Timezone handling has carried forward. Dependencies that affected Sprint 12 can be considered before the next commitment. Work that became ready in the meantime can enter the candidate pool alongside it. The Sprint 12 review remains in Wiki when the team needs the reasoning behind those decisions later.

There is no rule that Sprint 13 should therefore be larger, smaller, or more conservative. The next commitment is simply made with more information than the previous one.

Run Agile delivery from one Cycle to the next

A sprint gives the team something concrete to commit to. What happens during it tells the team when that commitment still makes sense, when the work needs to adjust, and when the plan itself needs another look.

In Plane, Agile delivery runs from one Cycle into the next. The team can plan the commitment, follow delivery as it unfolds, investigate unexpected work with Agents, keep the context worth carrying forward in Wiki, and bring what it learned into the next sprint.

Plan sprints and run Agile delivery in Plane

Bring ready work into a Cycle, commit to the sprint, follow delivery as it unfolds, and use what happened to plan the next one.

Get started with Plane