planning-the-worklisted

# Planning the work A plan exists to make the next person's decision easy. If a teammate reads your task and still has to ask what to build, it was not a plan. ## Start from the outcome Write the goal in one sentence, in the owner's terms, not the implementation's: "the API returns results in under a second for the top ten queries", not "add caching". Then work backwards. If you cannot state the goal that way, you do not understand the ask yet — go and ask. Check what already exists before you plan around it. Half of most plans is already in the repo. ## Cut it into tasks A good task: - **fits one run.** If it needs more, it is two tasks. Splitting is not optional — the app cuts a run off at its cap wherever it happens to be. - **has a definition of done** you could check without the author present: this test passes, this command prints this, this endpoint returns this. - **has one owner.** Two people on one task means neither is on it. - **stands alone, or names what it waits on.** Say the order explicitly rather than hoping. Cut along seams the code already has. A task that touches nine files across four areas is usually one task pretending, and it will collide with everyone else's work. ## Sequence it honestly Put first the thing that most likely proves the plan wrong. If a spike is needed to know whether the approach works, that is task one and everything after it is provisional — say so, rather than laying out five confident tasks built on an assumption nob