Write a task small enough to reject
Small tasks help when each task ends in a meaningful decision.
“Finish the export system” can contain several days of incompatible decisions. One worker might start with PDF generation, another with the toolbar, and a third with the handling of malformed diagrams. By the time the reviewer sees the result, the useful and broken changes may be difficult to separate.
My January plan for Kelpie, a document-editing and export application, began with twelve phases. Three days later, I asked to replace that arrangement with feature groupings and much smaller tasks in the project requirements document. I specifically wanted rigorous pass-or-fail criteria. The record preserves the request and an assistant’s claim to have produced a package; it does not independently verify that every resulting task was implemented.
The change in task size is worth examining because small tasks can still be badly defined. “Create an export button” is short, but a button that does nothing is an incomplete user action. A useful unit of work ends where a reviewer can accept or reject a coherent behavior.
Choose a complete behavior
Take an illustrative application that exports a selected document. A reasonable first task might let the person export a plain-text document as a PDF and then display where the file was saved. The task can exclude diagrams initially, provided the interface identifies that limitation rather than suggesting that every document is supported.
The worker needs the existing document interface, the permitted output location and a sample document. Acceptance requires that the button uses the selected document, creates the file, preserves its text and reports a useful error when writing fails. That is more work than adding a button, but it leaves a behavior that can be demonstrated from start to finish.
The next task can add diagram support against another fixture. A fixture is a saved example used repeatedly in a test. The first fixture should remain in the test set so the new feature cannot quietly break the earlier behavior.
There is no universal number of lines or minutes that makes a task appropriately small. The practical question is whether a reviewer can identify the intended behavior, inspect the relevant change and explain a rejection without reconstructing the whole application.
Name the dependencies that would otherwise become guesses
The diagram task depends on a rendering interface. If that interface does not exist, the worker must either create it within the task’s scope or report the missing prerequisite. It should not invent an incompatible temporary interface and leave the integration problem for a later task that has not been authorized.
A task description can make this straightforward. Name the prerequisite, identify its current version or location and state which behavior the worker may assume. When an assumption proves false, the failure is useful information about the plan rather than an invitation to expand the task indefinitely.
Keep completion evidence close to the task. A short record might identify the changed files, the input used and the observed output. It should also distinguish an automated check from a manual observation so the next worker knows which parts can be repeated without reconstructing the reviewer’s judgment.
Before assigning the diagram task, ask a reviewer to walk through its acceptance example using the existing application and identify exactly where the current behavior stops, recording that point with the sample input and observed result. If the reviewer cannot tell whether the missing behavior belongs to import, rendering or export, split the investigation from implementation and resolve that uncertainty before several workers begin making incompatible assumptions about the same document.
Avoid splitting only to increase the completion count
A task list can become impressively long while the product remains unusable. Separate stories for a button, a handler, a route and a placeholder response may produce four successful statuses without producing one successful export.
Splitting helps when it reduces uncertainty or isolates a failure. It is less useful when every completed item needs several unfinished items before anybody can use it. If the only demonstration available requires describing what future workers will add, the task probably needs a different boundary.
For the export example, stop the first task after a person can select a supported document, save its PDF and locate the result. Leave the richer document types for later tasks with their own fixtures. The reviewer then has a working behavior to preserve and a specific limitation to remove, rather than a collection of parts whose eventual relationship remains untested.
Source notes
Drew Wiberg, Kelpie planning revisions, 20 and 23 January 2026. Contemporary author records; establish the change from phases to granular requirements.
Worked examples and review procedures in this article are instructional applications, not additional historical project results.
