Sprints in Plane: Setting Up Cycles Without Missing Releases

Sprints in Plane are run through Cycles: a cycle has dates, a set of work items and progress, and features that take longer than one sprint are grouped into Modules. To keep releases from slipping, you need three things: a fixed cycle length, estimates before planning, and a rule for how many work items can be in progress at once. The tool provides the structure, but deadlines are held by the discipline of team rituals.

This article is for team leads, product managers and engineering leads who are moving to Plane from Jira or introducing Agile to their team for the first time. Below: how cycles and modules work, how to set up estimates and statuses, which charts to watch, how to run rituals in Plane, a day-by-day calendar for a two-week sprint and the mistakes that make releases slip.

Cycles and modules: two planning axes

The main mistake when moving from Jira is trying to find an exact copy of the sprint and the epic in Plane. Plane has two independent axes.

A cycle is time. Two weeks during which the team commits to completing a specific set of work items. Cycles follow one another, and each has a start and end date.

A module is an outcome. A feature, a project phase or a large enhancement that can take several cycles. A module shows how many of the feature’s work items are done and how many remain.

A work item belongs to one cycle and one module at the same time. During planning, you pull work items from different modules into the cycle, and at the product review you look at how far each module has progressed. In 2026, Plane added epics as a work item type and Releases, so large initiatives can be described as an epic and deliveries recorded as a release. For a team of up to 30 people, the “cycle + module” combination is usually enough.

If the team is moving from Jira, keep in mind that the importer migrates sprints, but epics arrive as a regular work item type. It’s worth rebuilding them as Plane modules or epics right away. We described a detailed migration plan in our article on migrating from Jira to Plane.

Setting up a project for sprints

Before the first cycle, set up the project once, so you don’t have to change the rules mid-sprint.

1. Statuses. Five to seven statuses are enough: Backlog, Ready, In Progress, Code Review, Testing, Done, Canceled. The “Ready” status means the work item has a description, acceptance criteria and an estimate.
2. Estimates. Turn on estimates in project settings: points, categories or time. Product teams usually prefer points or categories; teams with hourly contracts prefer time.
3. Work item types. At a minimum: story or feature, bug, technical task. Don’t create ten types on day one.
4. Labels. By component or type of work: backend, frontend, mobile, infrastructure.
5. Cycle length. Choose one length and don’t change it for at least a quarter.
6. Definition of done. Write down on the project page what “Done” means: code in the main branch, tests passed, work item shown to the product manager.

Estimates, capacity and limiting work in progress

Estimates aren’t for reporting to management; they’re there so you don’t take more into a cycle during planning than the team can deliver. After three or four cycles, the team has a velocity: how many points it closes per cycle. That number is the capacity for the next planning session, adjusted for vacations and holidays.

A simple way to calculate the adjustment: take the average velocity over the last three cycles and multiply it by the share of available person-days. If the team has five people, the cycle is ten working days long and one developer is on vacation for a week, 45 of 50 person-days are available, so you should take on about 90% of the usual volume. The calculation is rough, but it beats planning “by feel.”

Estimation rules that work:

• The team estimates, not the team lead alone.
• A work item larger than half a cycle is split before planning.
• A bug that can’t be reproduced isn’t estimated and isn’t taken into the cycle.
• Estimates aren’t changed retroactively to close the cycle “nicely.”

WIP, the number of tasks in progress at the same time, is the main lever for hitting deadlines. When a developer has five work items “In Progress,” none of them reaches testing by the end of the cycle. We introduce the limit as a team rule: no more than two work items “In Progress” per person and no more than three in “Code Review” for the whole team. Violations are visible in the cycle view grouped by assignee. A new work item is picked up only after the previous one has moved on.

Charts and dashboards: what to watch during a cycle

In the cycle card, Plane shows progress: how many work items and estimate points are closed, how many are in progress and how many haven’t started. That’s enough for a daily look. For managers, Plane dashboards are more convenient, bringing several projects and metrics together on one screen.

What to watch and how to read it:

• Cycle progress by day. If less than a third is closed by mid-cycle, the cycle is at risk. That’s a reason for a conversation at the daily, not on the last day.
• Work items with no movement. A filter for work items that haven’t changed status in a while shows where the team is stuck.
• Added after the start. Every work item added to the cycle after planning pushes something else out. They’re worth counting.
• Carried over from the last cycle. If the same work items are moving for the third time, they’re too big or nobody needs them.
• Module progress. Shows the product manager when a feature will be ready for release.

Complex queries are easy to build with PQL, Plane’s query language similar to JQL, and save as views.

Rituals in Plane

Rituals don’t change when you switch trackers, but each one gets its own place in the tool.

Ritual	When	What we do in Plane
Backlog grooming	Mid-cycle, 1 hour	Backlog view filtered by “no estimate,” split and estimate work items, move them to “Ready”
Planning	First day of the cycle, 1–2 hours	Create a cycle with dates, move work items from “Ready” up to capacity, check blocked-by relations
Daily	Every day, 15 minutes	Cycle board grouped by assignee, look at blocked work items and WIP violations
Review and demo	Last day of the cycle	List of the cycle’s completed work items, update modules and the release
Retrospective	After the demo, 1 hour	Retro page in Pages, improvements turned into work items in the next cycle
Release	When a module is ready	Release in Plane with a list of work items, release notes on a page

For distributed teams, the daily can be partly moved to an asynchronous format: by a set time, everyone leaves a short comment on their cycle work item, and a call is held only for blocked items. That way, status stays in the tracker rather than in chat, and anyone who opens the cycle can see it.

Retros are best kept in Pages within the same project: six months later, they show which problems keep recurring. Every retro decision becomes a work item with an owner; otherwise the retro turns into a conversation with no consequences.

Reminders about grooming or unestimated work items can be set up with Automations and Runner, Plane’s scheduled automations. Start with one or two rules, not a dozen.

A two-week sprint, day by day

A calendar for a two-week cycle that we use as a starting point. It gets shifted for a specific team, but the order stays the same.

Day	What happens	What to check in Plane
1, Monday	Planning, cycle start	Cycle created, work items within capacity, each one has an owner
2–4	Development, dailies	No work items stalled for more than two days, WIP within the rule
5, Friday	Quick progress check	At least a third of the estimate points closed, risks named
6, Monday	Grooming for the next cycle	“Ready” has work items for the next cycle
7–8	Development, code review	The “Code Review” queue isn’t growing
9, Thursday	New work freeze, testing	No new work items added to the cycle, everything unfinished discussed
10, Friday	Demo, retro, cycle close	Unfinished work items handled explicitly, retro recorded, modules updated

The day-nine rule is the most useful: after it, nothing gets added to the cycle. Anything urgent goes into the next cycle or, if it’s an outage, through a separate incident flow.

Bugs and urgent work inside a sprint

A sprint breaks not only because of poor planning but also because of a stream of urgent work: production bugs, requests from sales, asks from management. You can’t ban urgent work, but you can make it visible and limited.

Three techniques work:

• A capacity buffer. During planning, the team leaves part of its velocity free for unplanned work. How much exactly is visible from history: look at how many work items were added to past cycles after they started.
• A separate entry point for requests. Requests from support and sales come in through Intake rather than as direct messages to developers. The on-call person triages them once a day and decides what goes into the current cycle and what goes to the backlog.
• A bug duty rotation. One developer per cycle is responsible for urgent bugs and takes fewer planned work items. The role rotates so that no single person burns out.

Every work item added to a cycle after it starts should displace another item of comparable size. If the team only adds and never removes, a slipped release is predictable in advance. An “added after start” label helps the retro show how much work came from outside and from where.

For teams where more than half the work is urgent, Scrum with strict cycles may not fit. A kanban flow in Plane without cycles, with a WIP rule and a weekly release, works better for them.

Common mistakes that make releases slip

• The cycle as a wish list. Everything the team would like to do goes into the cycle. Capacity isn’t calculated, and half the work items are left over every cycle.
• Automatically carrying over leftovers. Unfinished work items silently move into the next cycle. The team stops noticing that it plans poorly.
• A module without an owner. No one is responsible for the feature’s release readiness, and the last ten percent of the work hangs for months.
• Estimates in days with no buffer. A “two days” estimate doesn’t account for code review, testing and calls.
• Tasks from chats bypassing the cycle. A manager messages a developer directly, the task never reaches the tracker, and the cycle slips for an invisible reason.
• The daily as a status report. Everyone recounts what they did instead of discussing what’s blocking the cycle from closing.
• Changing the cycle length. One cycle is two weeks, the next three, then one. Velocity becomes impossible to compare.

Kazakhstan context. Many teams are distributed between Almaty, Astana and remote work, so dailies and planning happen online, and agreements easily get lost in WhatsApp. The rule “a task exists only in a Plane cycle” matters even more here than in an office-based team. Factor holidays into capacity: around Nauryz in March and the May holidays, a cycle can lose several working days. If work items and attachments contain customer data and it matters to the company to keep it in Kazakhstan, install self-hosted Plane on a server in Kazakhstan: the vendor’s cloud stores data abroad.

If the team is introducing goals at the same time, it’s convenient to link cycles to quarterly OKRs. We covered how to do that in our article on OKRs in a task tracker.

How we do it

We start with a diagnostic: how the team plans today, how many work items on average aren’t closed in a sprint, where requirements get lost and who decides what goes into a release. Then we run a pilot with one team for two or three cycles in Plane, set up statuses, estimates, views and rituals, and adjust the rules based on the retros. After that, the setup is rolled out to the other teams without changing the core rules.

Learn more about how implementation works on the Jira and Plane task tracker implementation service page.

---

Sources. Plane pricing and features: plane.so/pricing. New Plane features: Plane blog. Community Edition source code: github.com/makeplane/plane.

Terms in plain words

Agile

An approach to development in which a product is built in short iterations and results are shown regularly. It lets you get feedback quickly and change priorities without derailing the whole plan.

Sprint and Cycle

A fixed period, usually two weeks, for which the team commits to a specific set of tasks. In Plane, sprints are called cycles.

Module

A group of work items for one feature that may span several consecutive cycles. It shows the product manager how ready the feature is for release.

WIP limit

A cap on the number of tasks a person or team keeps in progress at the same time (Work in Progress). The less work is started, the more tasks reach done by the end of the sprint.

Capacity and velocity

Velocity is how many estimate points the team closes per cycle on average. Capacity is how much it can take into the next cycle, adjusted for vacations and holidays.

Backlog grooming

A meeting where the team goes through the queue of upcoming tasks: clarifies descriptions, splits large items and estimates them. Without it, planning turns into guesswork.

Daily and retrospective

The daily is a 15-minute meeting every day about what’s blocking the cycle from closing. The retrospective is a review after the cycle: what to improve, with a task and an owner for each decision.

Scrum and kanban

Scrum means working in fixed sprints with planning and demos. Kanban is a continuous flow of tasks with a limit on work in progress; it suits teams with a lot of urgent work.