Cycles, milestones, initiatives & releases

The planning layer

Tasks are the unit of work in Elliptic, but real planning happens above a single task. You run work in time-boxed iterations, you commit to dated checkpoints, you group features into workstreams, you roll several projects up under one strategic bet, and you bundle finished work into versioned releases. This page covers all of those, plus the timeline and insights that show whether the plan is holding. Every surface here is also reachable by your agents over the company-brain MCP, so an agent can plan a cycle or tag a release the same way you do, on your organization's own model key.

Cycles (sprints)

A cycle is a time-boxed iteration inside a project, what other tools call a sprint. It has a name, an optional start_date and end_date, and a status that moves through three states: upcoming, active, and completed. You assign work items to a cycle, run the cycle, and at the end you see exactly what got done. Cycles live per project, so each project keeps its own cadence.

Creating and assigning work

Create a cycle with a name and, if you want a fixed box, a start and end date. New cycles begin life as upcoming. To put work into a cycle, assign a task to it. A task can be moved into a cycle and back out again while the cycle is still open, so an upcoming cycle is also where you stage the work you intend to commit to next. Once a cycle is completed it locks, and its assignments can no longer change.

1. 1
   Create the cycle

   Give it a name like Sprint 24 and, optionally, a start and end date. It starts as upcoming.
2. 2
   Assign work

   Add tasks to the cycle. Assign and unassign freely while the cycle is still upcoming or active.
3. 3
   Start it

   Starting a cycle flips it to active and stamps the moment it began.
4. 4
   Complete it

   Completing a cycle closes it out and freezes its final counts for velocity.

The lifecycle: upcoming, active, completed

Starting a cycle moves it from upcoming to active and records started_at. By default a project allows only one active cycle at a time, so you complete the current one before starting the next, unless the project has parallel cycles enabled, which permits overlapping active cycles. Completing a cycle moves it to completed and records completed_at. Completion also captures the cycle's final scope and finished count as final_total_count and final_completed_count, a frozen snapshot that does not change afterward even if the underlying tasks move. That frozen pair is what makes velocity trustworthy over time.

Rolled-up counts

Every cycle reports a live breakdown of the work assigned to it across four buckets:

• Total: every active work item assigned to the cycle. Cancelled and duplicate items are left out of the total.
• Done: items in a completed status.
• Started: items that are in progress.
• Todo: items not yet started, merging the backlog and unstarted categories.

These counts power the per-cycle progress bar and feed the workspace dashboard. The dashboard surfaces your organization's active cycles across all projects in one place, each with its own done-out-of-total rollup and the name and key of the project it belongs to, so you can see every sprint in flight without opening each project.

Transferring incomplete work

When a cycle ends with work unfinished, you do not have to reassign each item by hand. Transfer moves every incomplete item from the cycle into a follow-up cycle you choose, in one action, and tells you how many items moved. The natural flow is to create the next cycle, complete the current one, then transfer the leftovers forward so nothing falls through the cracks.

Recurring cycles and velocity

Generating a dated series

If your team runs on a fixed cadence, you do not need to create each sprint manually. Generate auto-creates a whole series of future cycles at once from a small config. You give it a base title, how many cycles to create, how long each one runs, an optional gap between them, the date the first one starts, and the number to start counting from.

Each generated cycle is dated back to back, offset by its duration plus the cooldown, and numbered from the start index, so its name reads like Sprint 1, Sprint 2, and so on. A typical setup is twelve two-week sprints starting next Monday with no cooldown, which lays out roughly half a year of cadence in a single call. Generated cycles arrive as upcoming, ready for you to start when their time comes.

Velocity

A project's velocity is the series of frozen completed-and-total counts across its completed cycles, plus a rolling average velocity over them. Because each cycle's numbers are frozen at completion, the series is a stable historical record rather than a number that drifts as old tasks get reopened or moved. The velocity view returns one point per completed cycle (its name, when it completed, how many items it finished, and its total scope), the average finished count across those cycles, and the count of cycles included.

Milestones

A milestone is a date-anchored delivery checkpoint inside a project. Where a cycle is a box of time, a milestone is a commitment to a date: a launch, a demo, a go-live. Each milestone has a name, an optional description, an optional target_date, and a status of either upcoming or completed. You link the work items that have to land for the milestone to be met, and the milestone tells you how close you are.

Linking and bulk-linking items

Link a task to a milestone one at a time, or bulk-link many at once by passing a list of work items in a single call (1 to 200 items). Bulk linking returns a per-item result, the outcome for each item, so you can see what was linked. You can unlink any item later, and you can list every task currently attached to a milestone to review scope.

Done and total rollups

Each milestone rolls up a simple done-out-of-total count over its linked items: total is everything attached, done is everything in a completed status. That ratio is the at-a-glance read on whether a dated commitment is on course. Milestones split into upcoming and completed, so the ones still ahead of you stay separate from the ones already shipped.

Modules (workstreams)

A module is a feature grouping or workstream inside a project. Where a cycle answers "when" and a milestone answers "by what date", a module answers "what part of the product". Use modules for streams like Billing, Onboarding, or Mobile that run across many cycles. A module carries a name, an optional description, an optional lead, an optional start_date and target_date, a status, and an optional link to a milestone.

Status

A module's status describes the health of the whole stream, independent of any single task:

• Planned: the workstream is defined but not yet underway.
• In progress: active work.
• Paused: temporarily on hold.
• Completed: the stream has delivered.
• Cancelled: the stream was dropped.

Counts, archiving, and export

Like cycles, modules roll up their linked work across total, done, started, and todo, and a project-level summary aggregates across the project's modules. You assign and unassign tasks per module. When a stream is finished or shelved, archive it to clear it from the default list without deleting anything, and restore it later to bring it back. Listing can optionally include archived modules when you need the full history.

Each module can be exported to CSV for reporting or migration. The export contains one row per linked work item with its number, title, status, priority, kind, and assignee id, and it neutralizes spreadsheet formula injection on text fields so the file is safe to open.

number,title,status,priority,kind,assignee_id
42,Wire up billing webhook,in_progress,high,task,
43,Retry failed charges,todo,medium,task,

Initiatives

An initiative is an organization-level strategic grouping that sits above projects. Where cycles, milestones, and modules organize work inside one project, an initiative pulls several projects together under one goal, something like Q3 Expansion or Enterprise Readiness. Each initiative has a name, an optional description, an optional target_date, and a status of active, completed, or archived.

Linking projects and rolling up progress

You link projects to an initiative and unlink them as priorities change. The initiative then rolls up everything underneath it: how many projects it contains, and the combined task progress across them as total, done, started, and todo. It also computes a weighted view of progress so larger projects count for more than smaller ones, which the interface shows as a percent done "by effort" alongside the raw item count. The Initiatives page offers list, board, and timeline views, and the timeline plots each dated initiative by its target date so you can see the portfolio sequenced over time.

RAG updates

An initiative can carry a running log of updates, each a short status post with a RAG health and a summary. The health is one of on track, at risk, or off track, the same red-amber-green vocabulary used for project updates. Posting updates over time gives the initiative a narrative of how confidence has shifted, which is exactly the kind of context an executive review or an agent summarizing the quarter needs.

Releases and the changelog

A release is an organization-level versioned deliverable, the bundle of work shipping together. A release has a name, an optional version string, an optional description, an optional released_at date, and a status of planned, released, or archived. You tag work items into a release from any project, and the release rolls up a done-out-of-total count so you can see how much of the version is ready.

1. 1
   Create the release

   Name it, optionally give it a version like v1.2.0 and a target release date. It starts as planned.
2. 2
   Tag the work

   Tag the work items that ship in this version into the release. Untag any that slip to a later one.
3. 3
   Track readiness

   Watch the done-out-of-total rollup as tagged items complete.
4. 4
   Ship it

   Flip the status to released when it goes out, and archive it once it is historical.

The Keep-a-Changelog changelog

Each release carries a structured changelog that follows the Keep a Changelog categories. Every entry has a category, a title, an optional body, and an optional PR link, and entries keep an explicit sort order so you control how they read. The six categories are:

Because an entry can link the pull request that delivered it, the changelog stays traceable back to the code. This is a natural surface for an agent: with a release tagged, an agent can read the shipped items and draft categorized changelog entries with PR links for you to review.

Timeline and scheduling

The project timeline is a Gantt view of every dated, non-triage work item in a project, drawn from each task's start and due dates and connected by scheduling dependencies. On top of the bars it computes two things that tell you where the plan is fragile: the critical path and any violations.

Critical path and violations

The critical path is the longest chain of dependent work through the project, the sequence that sets the earliest the project can finish. Tasks on it are flagged so you know which slips actually move the end date. A violation is a scheduling link whose current dates break its own constraint, for example a successor that starts on or before its predecessor finishes under a finish-to-start link. The timeline marks every violated link and every task on the receiving end of one, and reports a total violation count so you can see at a glance whether the schedule is internally consistent.

Scheduling dependencies

A scheduling dependency constrains one task's dates relative to another's. It is distinct from a logical task relation: a relation says two items are connected, a scheduling link actually drives the timeline. You create one by pointing a task at another, choosing the dependency type, and saying which of the two is the predecessor. There are four types, the standard project-management set:

Auto-shift cascades

When you move a task's dates, auto-shift cascades the change down the dependency chain so the schedule stays valid. It walks the dependents in dependency order and pushes each successor just far enough to satisfy its constraint. The cascade is forward only: a successor is only ever pushed later, never pulled earlier, and a task's duration is preserved when its start moves. Auto-shift returns exactly which tasks moved and their new dates, so a date change you make in one place resolves the downstream knock-on effects in one step instead of leaving you to fix each violated link by hand.

Insights

Once work is flowing through cycles and projects, the insights surfaces tell you how it is going.

Throughput trend

The throughput trend plots created versus resolved work items over a trailing window, with one point per day. The default window is the last 30 days and can run from 7 up to 90. Two lines, items created and items resolved, let you read at a glance whether you are keeping pace with incoming work or falling behind. When the resolved line tracks or beats the created line, the backlog is holding steady.

Project overview stats

The analytics overview rolls up a project (or the whole organization) into a compact snapshot: total items, completed items, a completion rate, and how many are overdue, plus breakdowns by status category, by priority, and by work-item kind. The same rollups can be exported to a long-format CSV of metric, dimension, and value for reporting elsewhere.

Epics view

The epics view lists the project's work items of kind Epic and shows progress per epic from its child items, a done-out-of-total of the subtasks underneath it, along with the summed estimate points rolled up from its children. It is the way to see large bodies of work as single rows while keeping the detail of what is finished underneath each one. For deeper cuts, the analytics module also offers flow and WIP across the open statuses, per-member workload, a scope-versus-completion scatter across cycles or modules, a configurable pivot, and a weekly throughput forecast.

Putting it together

These pieces are designed to layer. Inside a project you run work in cycles, commit to dates with milestones, and organize streams with modules, while the timeline keeps the dependencies honest. Above projects, initiatives group the portfolio and releases bundle what ships, and insights tell you whether the whole thing is converging. Because each surface is available to agents over the company-brain MCP on your own key, the same planning loop your team runs by hand is one your agents can run alongside you.