Where Your Cold-Start Number Should Actually Come From

We've written before about PtahCast's cold-start mechanism — the provisional throughput estimate that lets a brand-new project get a forecast before it has any completed tickets of its own. What we haven't covered is where that starting number should come from, because "just pick something reasonable" is not a plan. PtahCast has a specific tool built for exactly this: the per-person throughput report.

One question, answered honestly

The report exists to answer a single question: how many tickets has this person actually completed, historically, across everything they've worked on in PtahCast? It's deliberately narrow. It doesn't rank people against each other, doesn't flag anyone as fast or slow, doesn't editorialize in any way. It shows a count. Whatever conclusion you draw from that count is your judgement, not the software's opinion.

That restraint is a feature, not a limitation. A tool that ranks people invites the wrong conversations. A tool that just shows the number invites the right one: given what this person has actually delivered elsewhere, what's a fair starting estimate for the work they're about to join?

How "completed" is counted — and why it's counted that way

A ticket counts toward someone's total if they appear anywhere in that ticket's history, not only if they made the final move into Done. This is a deliberate choice. In a typical dev-review-done workflow, the person who did the bulk of the real work is frequently not the person who clicks the ticket into Done — a report that only counted the final click would make most of the actual effort invisible. A ticket that bounced back and was re-touched by the same person still counts once, never inflated by repeat handling.

The count also spans every project in the instance, active or archived. Someone's track record on a project that's since been archived is still real evidence of how they work — it doesn't stop counting just because the project itself is no longer on the dashboard.

From report to forecast

Open the report index and every user shows their all-time total. Drill into any one person and you get a week-by-week breakdown — 13, 26, or 52 weeks, your choice — plus the total, average per week, and the min/max in a single week. That per-week average is exactly the shape of number the starting weekly throughput field is asking for.

So the workflow this enables is straightforward: before typing a number into a new project's starting throughput field, check the report for the people actually joining that project. If two developers who've historically completed six and four tickets a week respectively are about to start together, "five per week" is a defensible starting estimate — grounded in their real record, not in optimism about a fresh start.

The through-line

Every part of PtahCast's forecasting story points back to the same principle: real history beats confident guessing, at every stage. The per-person report is where that principle reaches all the way back to the very first number you ever type into the system — the one that has to stand in for real data until real data exists.

Delivery Dates