Small and independent

Most of the six letters reinforce each other. Two do not. Small wants the thinnest possible slice; Independent wants a slice that does not wait on its neighbours. Making a story smaller can introduce a dependency: split “enrol and see the confirmation” into “enrol” then “see the confirmation”, and the second half now waits on the first.

The trap is splitting along technical layers — the table, then the API, then the page. Each layer is small, but none ships value on its own, so each fails Independent: the API waits on the table, the page waits on the API. The resolution is to split along value: cut the work so each slice is a whole capability, demonstrable by itself. “Browse the catalogue” and “enrol in a course” are both small and independent because each is a complete thing a learner can do.

The hero shows that the right split keeps slices independent. This view proves the other half: a small story is estimable almost by definition. Drag a story's size from the whole catalogue down through the ladder rungs. At each step the figure reports whether Small passes and whether Estimable passes — and Estimable flips to pass at exactly the same step Small does.

That is not a coincidence. A slice that fits one rung has little of it to misjudge, so the cost is a guess anyone can make. A too-big story fails Small and Estimable together, because its size is exactly what makes the estimate a guess in the dark. Estimability is not a separate judgement to apply — it falls out of smallness.

On the Portal, “manage the whole catalogue” fails Small and Estimable. Splitting it along value yields the story ladder: browse → enrol → open a lesson → track progress. Each rung is small (one turn), estimable (small implies estimable), and independent (a whole capability a learner can be shown). The ids the rungs rest on are already minted — Portal.ID.generate/1 hands back a typed id, and Portal.ID.decode/1 reads its .type back — so no rung waits on another to define its identifiers.

Splitting along layers would have produced “the courses table”, “the courses API”, and “the courses page” — three slices that each fail Independent, because none is demonstrable on its own. Same destination, but the value split keeps every slice shippable in isolation. The mechanics of the cut are A2.05; the reason to cut along value is that it is the only split that satisfies Small and Independent at once.

# "manage the whole catalogue" — fails S and E. Split it.

# Split by VALUE → each slice is small, estimable, AND independent:
#   browse  → enrol  → open a lesson  → track progress      (4 / 4 independent)

# Split by LAYER → each slice is small but coupled:
#   courses table → courses API → courses page             (0 / 3 independent)

id = Portal.ID.generate(:course)        # ids are already minted — no rung waits on another
assert Portal.ID.decode(id).type == :course

Small and Independent are the two INVEST letters that pull against each other: shrinking a story can couple its pieces. Splitting along value rather than along technical layers satisfies both, because each value slice is a whole capability that ships alone. Estimability is not a third thing to check — it follows from smallness, flipping to pass exactly when Small does. On the Portal, “manage the catalogue” splits along value into the four-rung ladder. That closes A2.03: a story is ready when the six tests pass, a smell names the letters when they do not, and value is the axis that keeps Small and Independent together. The mechanics of the cut are the next module.

The story-splitting and estimation sources behind this tension, and where it connects in the course.