We Stopped Estimating. Here's How PtahCast Predicts Delivery Dates Instead.

Every team has had the conversation. A stakeholder asks "when will this be done?", someone throws out a date built on story points and a gut feeling, and three weeks later everyone is explaining why it slipped.

PtahCast was built to remove that guesswork — not by making estimation more rigorous, but by getting rid of it entirely. Here's how the workflow actually works, end to end.

The backlog: Inbox and Ready, not one big pile

Every new ticket in PtahCast lands in the Inbox. It's the holding area for work that hasn't been groomed yet — a raw idea, a bug report, a request from a stakeholder.

Nothing moves from Inbox onto the board directly. It has to pass through Ready first — the lane for work that's actually been thought through.

To help with that, every project gets a Definition of Ready checklist: acceptance criteria defined, scope stated, no unresolved dependencies, reproduction steps for bugs, and so on. As a ticket gets groomed, you tick items off, and the checklist's progress fraction (say, 5/7) shows exactly how ready it is.

Here's the deliberate part: the checklist is advisory, not a hard gate. You can promote a ticket to Ready with 3 of 7 items ticked if that's the right call. PtahCast trusts teams to know when something's ready — it just makes sure "ready" was a conscious decision, not an accident, and every promotion and demotion is logged with a timestamp so that decision is never lost.

Pulling tickets onto the board, on purpose

This is the part most tools get backwards. In PtahCast, work doesn't get pushed onto the board by whoever's typing fastest — it gets pulled.

Only tickets sitting in Ready are eligible. When someone has capacity, they open the pull drawer, see every Ready ticket, choose a destination column, and pull it across. That single design choice — pull, not push — is what keeps a board honest. Nobody can dump ten half-formed tickets on the team on a Monday morning.

WIP limits: the constraint that makes flow visible

Every column can carry a WIP limit — a hard cap on how many tickets are allowed in it at once. Try to drag a ticket into a column that's already at its limit, and the move gets rejected outright, not just flagged.

This is the mechanism, not just a nice-to-have. Limiting work in progress is what turns "everyone's busy" into "work is actually moving." A column that's constantly bumping against its WIP limit is telling you something concrete: that stage is a bottleneck, and no amount of individual effort elsewhere in the pipeline will fix it until that constraint is addressed.

Forecasting: throughput, not estimates

This is where PtahCast earns its name. When it's time to answer "when will this be done?", PtahCast doesn't ask anyone to size anything. It runs a Monte Carlo simulation using one input only: how many tickets your team has actually completed, week by week, in the recent past.

The logic is straightforward once you see it:

1. Pull weekly throughput samples from your team's real history — a 30, 60, or 90-day window
2. Run 10,000 simulated futures. In each one, the engine draws a random week from your actual history and accumulates completed tickets until the remaining work is finished
3. Record how many weeks each of those 10,000 futures took

4. Sort the results and read off the percentiles That last step is where the forecast becomes useful:

5. P50 (Aggressive) — half of all simulated futures finished by this date. A coin flip. Good for internal optimism, bad for a promise.

6. P70 — a middle-ground marker between aggressive and commercial.
7. P85 (Commercial) — the number PtahCast recommends for actual stakeholder commitments. 85% of simulated futures beat this date.
8. P95 (Safe) — the conservative ceiling, for when being late genuinely isn't an option. No story points. No velocity chart someone gamed last sprint. Just your team's real, messy, historical pace, projected forward ten thousand times so you can see the shape of the uncertainty instead of pretending it isn't there.

Every forecast — at the epic level or the whole-project level — is saved permanently, so you can watch how the date has shifted as real work has landed, and export the full history as CSV, JSON, or a standalone PDF report for a stakeholder update.

Flow metrics: the evidence behind the forecast

Forecasting answers "when will this be done?" Flow metrics answer the question underneath it: "how has delivery actually been going?"

Four charts, all reading from the same transition history the forecast engine uses:

• Throughput run chart — tickets completed per week, with a mean line, so you can spot the weeks that dragged the average down
• Cycle time scatter — one dot per completed ticket, showing how long it took from being pulled to reaching Done, with P50/P85/P95 lines so outliers are obvious at a glance
• Work in progress over time — a stacked view of how many tickets sit in each column, day by day. A band that keeps growing relative to the others is a bottleneck forming in real time
• Cumulative flow diagram — the whole pipeline at once, from entry to Done. A band that flattens out means work has stopped moving through that stage None of this is opinion. It's a direct read of what actually happened, which is exactly what makes the forecast trustworthy — the simulation isn't projecting a hope, it's projecting your own recorded history forward.

Why it adds up to something different

Put together, the workflow is a straight line: groom deliberately (Inbox → Ready) → pull deliberately (WIP-limited board) → measure honestly (flow metrics) → forecast from what actually happened (Monte Carlo), not what someone guessed.

Every stage feeds the next one real data instead of a story. That's the whole premise of PtahCast — not a smarter way to estimate, but a way to stop needing to.

If you've ever had to defend a delivery date you didn't actually believe in, this is built for you.