Time estimates are a trap. Size tasks by effort instead.

Time estimates fail for a reason that has a name. Kahneman and Tversky called it the planning fallacy: people systematically underestimate how long their own work will take, even when they have every reason to know better, because we plan from a best-case story of the work rather than its messy reality. You aren't bad at estimating. Everyone is bad at estimating, predictably, in the same direction.

A time estimate pretends to answer "how long will this take?" — a question you cannot honestly answer before you start, because it depends on interruptions, unknowns, and how the work unfolds. So the number is false precision: it looks like information, but it's a guess wearing a lab coat. Then you plan your day around the guess, the guess is wrong, and the day collapses. You blame yourself instead of the method.

Worse, minute-level estimates invite over-planning. If tasks have times, you can "fit" them into a calendar, and now you're playing Tetris with your day instead of doing the work. The estimating becomes its own procrastination.

The question you can answer before starting isn't "how long?" — it's "how big?" Roughly: is this small, medium, or large? You know that immediately, by feel, without a calculator. Effort is relative, coarse, and honest, and coarse-but-honest beats precise-but-wrong every time you plan a real day.

This isn't a fringe idea. Basecamp's Shape Up frames work by appetite — how much time something is worth, not how long it will take — and then fits the work to the appetite. Agile teams moved to story points for the same reason: to size relative effort instead of pretending to clock-predict. The point is not the specific scheme; it's the shift from "estimate the clock" to "size the lump."

Story points solved the right problem and then re-complicated it — planning poker, Fibonacci sequences, team calibration meetings. For one person, that's the ceremony without the payoff. Three sizes is enough:

• Small — a single clean strike. You'll finish it in one sitting without thinking about it.
• Medium — real work, but bounded. One focused block.
• Large — this should probably be broken down, or it's a project pretending to be a task.

One tap, no poker, no false precision. And the sizes do something a time estimate never could: they let you balance a day. You can feel that three Larges stacked on a Tuesday is a lie before you commit to it. You can't feel that from "90 min + 90 min + 90 min."

This is the real objection, and it has a better answer than estimates. If you want to know when work will finish, don't predict each task — watch two things over time: how much you actually complete per week (throughput), and how long things sit before you finish them (work item age). Those are measured facts, not hopeful guesses, and they predict your future far better than any up-front estimate — the case for age-over-estimates is the spine of the agile-for-one method. Estimates predict from a story; throughput predicts from your track record.

1. Delete the times. Whatever field holds "30 min," ignore it. Stop feeding the fantasy.
2. Tag each task S, M, or L by gut. Don't deliberate — if you're unsure between two sizes, pick the larger one. You're always optimistic.
3. Break every L. A Large is a signal, not a size. Split it until the pieces are S or M, or accept it's a project and treat it like one.
4. Balance the day by size, not by clock. A sane day is a couple of Mediums and a Small, or one Large and nothing else. Feel the weight; don't add up minutes.

Sizing by effort is part of a larger discipline: fewer, rightsized commitments you actually finish — not a calendar of optimistic guesses. It pairs directly with capping work in progress and naming three things today.