Stop Estimating Effort: Why Your App Should Infer Task Size For You

The estimate is the first thing you get wrong

Open almost any serious task tool and it wants a number. Story points. Hours. T-shirt sizes. A little dropdown that says 'how long will this take?' — and it asks before you've done a single minute of the work. That's a strange moment to demand precision. It's the moment you know the least.

The uncomfortable truth is that people are systematically bad at this kind of guess, and we've known it for decades. The planning fallacy — our tendency to underestimate how long our own tasks will take even when we remember last time going long — was named by Kahneman and Tversky in 1979 and has survived every replication since. We don't just get individual tasks wrong; we get them wrong in a predictable direction, over and over, and we don't learn from it as fast as you'd hope.

So the estimate isn't a neutral input the tool needs. It's a fragile guess, made at the worst possible time, by the person least equipped to make it. And then the whole system — your day plan, your sprint, your sense of whether you're behind — gets built on top of that guess as if it were data.

Story points are theater (and everyone quietly knows it)

Agile tried to fix estimation by making it relative. Don't guess hours, the argument goes; just say this task is bigger or smaller than that one. Points, not time. And to its credit, relative sizing is genuinely less bad than pretending you can name the hour. Comparing two things is a task humans are better at than forecasting one thing in absolute terms.

But watch what actually happens to points in the wild. A team decides a point is 'about a day.' Velocity becomes a target instead of an observation. Managers ask why the number went down. Estimates inflate to protect the team, or deflate to look productive. The abstraction that was supposed to free you from time-guessing gets silently reconverted back into time-guessing, just with an extra ritual bolted on — planning poker, a meeting, a deck of cards — that makes the guess feel more rigorous than it is.

That's the theater part. The ceremony grows in proportion to how little anyone trusts the underlying number. If the estimate were reliable you wouldn't need three people, a Fibonacci sequence, and a re-vote to produce it. The elaborateness of the process is a tell: it's compensating for the fact that, at the end, it's still a guess about the future made by people who are bad at guessing the future.

• Points drift: 'a point is about a day' quietly turns relative sizing back into time estimation.
• The number becomes a target (Goodhart's law), so it stops measuring anything real.
• The ceremony scales with distrust — more ritual signals less confidence, not more.
• None of it removes the core problem: a forecast made before the work begins.

The tool is holding the one thing that could actually predict

Here's the reframe. You are not the best available estimator of your own tasks — but you have, sitting right there, a much better one: your own history. Every task you've ever finished is a labeled data point. It has a real elapsed time. It got carried over to the next day, or it didn't. You opened it once and closed it, or you kept coming back to it five times. That's not a guess about the future; that's a measurement of the past.

And crucially, the software is already holding all of it. Your task manager watches every task you complete. It knows which ones dragged, which tags tend to explode, which projects always run long. It has the ledger. The one entity in the whole system with the least excuse to ask you 'how big is this?' is the tool — because it's the only participant that actually remembers what things cost last time.

So the honest move isn't to make the estimation form prettier or the poker deck cleverer. It's to stop asking the human for a forecast and start reading the pattern out of the record. Not clairvoyance — nobody can see the future of a task that hasn't started. Just: 'the last handful of things that looked like this, for you, tended to be about this big.' That's a defensible starting point, and it's one you never had to type.

What 'infer a starting size' actually means

Inference isn't magic and it shouldn't pretend to be. The version I built into minino is deliberately boring under the hood, because boring is what earns trust. When a note becomes a task, it gets a starting size — one paw (a mouse), two (a cat), or three (a lion) — and that size comes from the most specific signal available, in order.

First it looks at your finished tasks that share a tag with this one. If there are enough of them, it takes the median of how they actually behaved and uses that. No matching tag? It falls back to the same project. No project history yet? It uses your overall pace across everything you've completed. And only when it has almost nothing to go on — a brand-new workspace — does it fall back to weak text signals, like the fact that 'refactor the auth flow' reads heavier than 'email Sam.' That cold-start guess is the worst one, and it's explicitly the last resort, not the default.

The key part is what counts as 'how it behaved.' It's not a number you entered. It's measured: days the task stayed open, how many times it got carried over to a new day, how many separate sittings it took. Friction shows up as size. A 'quick' task you reopened four times over a week was, in reality, a lion — and because completed tasks feed back in as training data, the engine learns that your 'quick' is not actually quick, without ever arguing with you about it.

• Signal order: shared tags → same project → your overall pace → (last resort) text length and phrasing.
• 'Size' is derived from measured behavior — elapsed days, carry-overs, distinct work sessions — not a self-report.
• Every finished task becomes labeled training data, so sizing reflects what things actually cost you.
• The paw badge is intentionally tiny. Sizing should feel like a stamp, not a form to fill in.

One-tap correction beats a required input

The obvious objection: sometimes the tool will be wrong. Of course it will. But 'wrong and correctable in one tap' is a completely different product than 'required and wrong.' A required estimate makes you stop, think, and manufacture a number every single time, including the ninety times out of a hundred when you have no real opinion and just want the task on the list. An inferred size makes you do nothing — unless it's off, in which case you tap once.

That asymmetry is the whole design. Correction is cheap and optional; the default costs you zero attention. And a correction isn't a complaint the system shrugs off — it's another signal. Tap the badge and it cycles mouse → cat → lion. Tap past a lion and it takes that as 'this is bigger than your biggest size,' and offers to break the task into an umbrella task with cubs underneath, which is exactly when a decomposition is worth doing. You steer only when you disagree, and your steering trains the thing.

I want to be precise about the claim, because overclaiming here is how you lose people. The engine is not a fortune teller. The honest framing is: it's wrong less often than you are, and it gets less wrong over time — because unlike your gut, it's keeping receipts. A guess you didn't have to make, that improves while you ignore it, and that you can override in a single tap, is strictly better than a mandatory guess that just sits there being confidently incorrect.

The category this points toward

Step back and the specific implementation matters less than the direction. There's a small but real category forming: a task manager without time estimates, a story-points alternative that doesn't just swap one guess-form for another. The unifying idea is that estimation is a job the software should quietly do from evidence, not a tax it collects from the user up front.

This isn't anti-planning. You still want to know whether tomorrow is realistic, whether a project is bigger than it looked, whether you're taking on three lions and calling it a light week. Those are exactly the questions inferred sizing can answer honestly, because it's grounded in your measured past rather than your optimistic present. The plan gets more trustworthy precisely because no human was asked to invent the numbers underneath it.

So if you're evaluating tools — or building one — the question worth asking is simple. When it needs to know how big a task is, does it interrogate you, or does it read your own history and let you correct it? The first is theater with extra steps. The second is the tool finally doing the job it was always best positioned to do. Stop estimating. Start finishing.

Frequently asked questions