TL;DR

• I built Cadence, an open source delivery analytics tool for Plane that surfaces cycle time, bottlenecks, team health, and Monte Carlo delivery forecasts
• It connects read-only to any Plane workspace, syncs issue history, and computes the metrics that Plane's board view does not show you
• This post walks through the Monte Carlo forecasting engine in detail — how it turns historical throughput into a probability distribution of delivery dates
• Live demo: cadence-plane-analytics.netlify.app
• Repo: github.com/kingztech2019/cadence-plane-analytics

The problem with project boards

Every team I have worked with uses some flavour of Kanban board. Plane, Jira, Linear, Trello — the shape is always the same. Columns for backlog, in progress, review, done. Cards move left to right. The board looks fine. Cards are moving. Sprints are closing.

And yet, deadlines keep slipping.

The board tells you the state of work right now. It does not tell you the things that actually determine whether you will hit your deadline:

How long does work actually take, from the moment someone picks it up to the moment it ships? Not the estimate — the real distribution, including the outliers.

Where does work get stuck? Not "QA is sometimes slow" — which stage, for how long, and is it getting worse?

Who on the team is quietly overloaded, and who has been stuck on the same ticket for three weeks?

Given everything we know about how this team has shipped over the last few months, what is the realistic range of dates for finishing what's left in this sprint?

Plane is a genuinely good open source project management tool. But like most PM tools, it shows you the board. It does not answer these questions. I built Cadence to answer them.

What Cadence does

Cadence connects to a Plane workspace — cloud or self-hosted — via API token or OAuth. It is strictly read-only; it never writes to your workspace, never modifies issues. It continuously syncs your issues and their full state-transition history into its own database, then computes a set of analytics that Plane's dashboards do not surface.

The metrics fall into three groups.

Delivery speed metrics — cycle time (with P50/P85 percentiles and scatter distribution), lead time (created to done, including wait time), flow efficiency (active time vs total time, benchmarked against the ~15% industry median), and sprint-over-sprint velocity comparisons.

Flow health metrics — a Cumulative Flow Diagram showing work-in-progress across stages over time, a bottleneck tracker that identifies which stage delays work most and escalates to "Critical" after three consecutive 30-day periods of being the bottleneck, scope creep tracking per sprint, and an At-Risk Radar showing in-progress issues that have already exceeded their stage's P85 duration.

Team and forecasting — per-person throughput and cycle time, team health flags for overloaded members and high reactivation rates, cross-project contributor views, and the Monte Carlo delivery forecast.

There is also a "Project Pulse" strip that appears on every page — a one-line signal surfacing the most important thing happening in a project right now, whether that's a new at-risk issue, a trend change, or a persistent bottleneck.

And an AI Sprint Retrospective feature, powered by OpenRouter, that generates a narrative comparing the current sprint to the prior one.

Deep dive: the Monte Carlo forecast

This is the feature I want to focus on, because I think it is the one most teams have never had access to, and it changes how you think about deadlines once you have it.

The problem with traditional estimates

Most teams forecast delivery dates by summing story point estimates and dividing by velocity. "We have 40 points left, we do 10 points per sprint, so 4 more sprints."

This produces a single number. A single number implies certainty. But software delivery is not certain — it is a distribution. Some tickets take half a day. Some take three weeks. The average hides the variance, and the variance is exactly the thing that determines whether your "4 sprints" estimate is realistic or wishful thinking.

What Monte Carlo simulation does instead

Instead of asking "what is our average throughput," Cadence asks a different question: "given everything we know about how this team has actually shipped work, what does a realistic range of outcomes look like?"

The approach is straightforward conceptually:

1. Take the team's actual historical throughput — how many issues were completed per week, for as much history as is available.
2. Run a simulation: starting from the current backlog size, repeatedly sample a random week's throughput from that history and subtract it from the remaining backlog, counting how many weeks it takes to reach zero.
3. Repeat this simulation 10,000 times.
4. Each of those 10,000 runs produces a "weeks to completion" number. Sort them.
5. The result is a distribution. The P50 (median) is the date by which there's a 50% chance you're done. The P85 is the date by which there's an 85% chance. The P95 gives you the conservative, "if things go badly" estimate.

This is fundamentally different from a single-point estimate. Instead of telling a stakeholder "we'll be done March 15," Cadence tells them "there's a 50% chance we're done by March 15, an 85% chance by March 22, and a 95% chance by March 29." That is a much more honest — and much more useful — thing to communicate.

Why sampling from real history matters

The key design decision is that the simulation samples from the team's actual historical weekly throughput, not from an assumed distribution like a normal curve.

Real team throughput is not normally distributed. It has good weeks and bad weeks — public holidays, a team member on leave, an unexpectedly gnarly bug that ate three days, a week where everything just clicked and the team shipped double the usual amount. A normal distribution would smooth all of that away. Sampling from real history preserves it.

This means the forecast naturally accounts for the team's actual rhythm, including its bad weeks, without anyone having to manually adjust for "but we have a public holiday next month" or "two people are on leave in March." If those patterns are reflected in the historical data — and over enough history, recurring patterns like holiday seasons tend to be — the simulation captures them implicitly.

Implementation shape

At a high level, the forecast computation in Cadence looks like this:

function monteCarloForecast(
  weeklyThroughput: number[],  // historical completions per week
  remainingBacklog: number,
  simulations = 10000
): { p50: number; p85: number; p95: number } {
  const results: number[] = [];

  for (let i = 0; i < simulations; i++) {
    let remaining = remainingBacklog;
    let weeks = 0;

    while (remaining > 0) {
      // Sample a random week from actual history
      const sampledThroughput =
        weeklyThroughput[Math.floor(Math.random() * weeklyThroughput.length)];

      remaining -= sampledThroughput;
      weeks++;

      // Safety cap to avoid infinite loops on zero-throughput history
      if (weeks > 520) break;
    }

    results.push(weeks);
  }

  results.sort((a, b) => a - b);

  return {
    p50: results[Math.floor(simulations * 0.50)],
    p85: results[Math.floor(simulations * 0.85)],
    p95: results[Math.floor(simulations * 0.95)],
  };
}

The actual implementation in Cadence does this as a PostgreSQL-backed computation over synced issue data — metricsService.ts builds the weekly throughput series from the issue state-transition history that the sync workers have already pulled in, then simulates that series.

A few practical details that mattered in getting this right:

Minimum history requirements. With very little history — say, two or three weeks — the simulation will technically run, but the result is close to meaningless. Cadence surfaces a warning when there isn't enough historical data for the forecast to be statistically useful, rather than presenting a confident-looking number built on noise.

Backlog definition. "Remaining backlog" needs a clear definition — is it all open issues in the project, or a filtered subset (a specific sprint, a specific label)? Cadence's forecast respects the same filter bar that every other metric page uses, so you can ask "given our current velocity, how long will it take to clear everything tagged v2-launch?"

Recomputation frequency. The forecast is recomputed as new sync data comes in, not on every page load. Running 10,000 simulations on every request would be wasteful given that the underlying data only changes when Plane issues change state — which the incremental sync picks up every 30 minutes, or in real time if webhooks are configured.

What this looks like in practice

On the Forecast page, you pick a target — typically "everything in the current sprint" or "everything in a specific milestone" — and Cadence shows you the P50/P85/P95 dates directly, along with the underlying throughput history the simulation drew from.

The practical effect: instead of a sprint planning conversation that ends with "we think we can get this done by Friday," you get a conversation that starts with "there's an 85% chance this is done by Friday, and a 50% chance it's done by Wednesday — do we want to scope down to hit the earlier date with more confidence, or are we comfortable with Friday as the realistic target?"

That is a fundamentally better conversation to have at the start of a sprint than at the end of it.

Architecture overview

For anyone interested in the broader system, Cadence is a Turborepo monorepo:

• apps/web — Next.js 15 (App Router), Tailwind CSS v4, Recharts for all the visualisations
• apps/api — Fastify 5 on Node.js 22, exposing the REST API and running the BullMQ workers
• packages/shared — TypeScript types shared between frontend and backend

The sync pipeline uses a two-priority BullMQ queue backed by Redis. When you connect a workspace, a high-priority job backfills the last 90 days of issue history first — typically done in about 5 minutes — so you have usable charts quickly, while a low-priority job backfills the complete history in the background, which can take 30-60 minutes depending on workspace size. After the initial backfill, an incremental sync polls Plane every 30 minutes for changes, with optional real-time updates via Plane webhooks (HMAC-SHA256 verified).

All of this runs against PostgreSQL 16, leaning on PERCENTILE_CONT for the P50/P85 calculations and window functions for the time-series metrics like the CFD.

Security-wise: Plane API tokens are encrypted at rest with AES-256-GCM, webhook signatures are verified with constant-time comparison, and shareable dashboard links use 16-byte random hex tokens that cannot be enumerated.

Try it

The whole thing is open source under AGPL-3.0. There's a live demo at cadence-plane-analytics.netlify.app, or you can self-host with Docker Compose:

git clone https://github.com/kingztech2019/cadence-plane-analytics.git
cd cadence-plane-analytics
cp .env.example .env
# set POSTGRES_PASSWORD, JWT_SECRET, ENCRYPTION_KEY in .env
docker compose up -d

Then open localhost:3001, sign up, and connect your Plane workspace URL and API token from Connections.

Discussion

I am curious about two things from teams using Plane, Jira, Linear, or similar tools.

First — if you have used Monte Carlo forecasting before (or tools like it, such as Actionable Agile or Nave), how has it changed sprint planning conversations on your team? Did stakeholders push back on probabilistic estimates versus single-date estimates?

Second — what metric do you wish your PM tool surfaced that it currently does not? I have a roadmap (multi-workspace comparisons, SLA tracking, label/epic analytics) but I would rather build what teams actually need than what I assume they need.

Drop your thoughts below. And if Cadence looks useful, a star on the repo helps others find it.