"Add user accounts" and "add the login form, no backend yet" are the same length as sentences. One of them is a month of work with no point at which you could stop. The other is an afternoon that ends with a page you can open.

Sizing is the decision that happens before any prompt, and getting it wrong is what produces the four-hour session that ends with nothing you can honestly call finished.

The idea

A piece of work fits one session when a single check would prove it done, and that check exists at the end of it. The unit of sizing is provability. If you cannot name the one thing you would run or click to see whether it worked, the piece is still too big to hand over.

text
"add user accounts"          4 outcomes, 3 layers, no single check
        |
        +--> login form, no backend yet
        |      check: /login renders, empty email shows an error, submit does nothing
        |
        +--> users table + migration
        |      check: pnpm migrate runs clean on an empty database
        |
        +--> signup writes a user and sets a session
        |      check: sign up, reload the page, still signed in
        |
        +--> password reset email
               check: request a reset, the email appears in the Resend log

How it works

Four signs the piece is too big:

  • You cannot write the check in one line. Two commands plus a browser walk plus an inbox means at least three pieces.
  • The files you would touch cross layers: a page, a database , an email service, a permission rule.
  • The sentence contains "and", or one of the words that hides a list: system, flow, management, support for.
  • Part of it waits on a decision you have not made yet. Whoever builds it will make that decision for you, quietly.

Three cuts that usually work. Cut by layer, building the visible surface against hard-coded data first and replacing the data later. Cut by path, building the case where everything goes right and handling the error cases in the next piece. Cut by user, making it work for one signed-in person before it works for teams, invites and roles.

The cut you want is one you could show someone. "The login form renders and rejects an empty email" is a slice a person can look at. "The auth service layer" is a slice nobody can check.

What to do

  1. Write the outcome in one sentence, then write the check under it. If the check needs more than one command or one browser walk, split before you start.
  2. Make the first slice the one that is visible. A screen against fake data teaches you more about whether the plan is right than a correct database schema with nothing on top of it.
  3. Put the cut-off work somewhere durable, in PROGRESS.md or your plan file, in the same minute you cut it. Work that is only postponed out loud comes back as a surprise.

Where it breaks

Some work resists slicing. A database migration that has to be applied as one step is one step, and cutting it in half leaves the database in a state neither half expects. A rename that touches forty files is one mechanical change, and doing it in four passes creates four broken intervals rather than one.

Slicing too finely costs real money. Every extra session pays the handoff again: reading the entry files, re-establishing what is true, writing the close. Three sessions to make one decision is worse than one session that holds it.

And you cannot size what you have not seen. When the work is "find out why the staging deploy is slow", the sizing question changes: bound the investigation by naming the evidence to collect and the point at which you stop, rather than pretending you can predict the fix.