Sprint Planning is a ceremony in which a team decides what to build in the next two weeks, how to build it, and — most importantly — which Fibonacci number to assign to each item, a process that consumes more time than several of the items being estimated.
Sprint Planning takes the simple human act of deciding what to do next and wraps it in a process: the Product Owner presents the backlog, the team discusses each item, the team estimates each item in Story Points, the team commits to a set of items based on their velocity, and the sprint begins. The process takes two to four hours. The decision — “what should we build next?” — takes about fifteen minutes. The remaining time is spent on the ceremony.
The fifteen minutes of decision-making is valuable. The ceremony around it is the tax.
The Estimation Tax
The majority of Sprint Planning is consumed by estimation — the act of assigning story points to work that has not yet been done, by people who have not yet done it, using a unit that has no external referent.
Story Points exist to answer the question: “How much work can we fit in two weeks?” The answer is always the same: less than you think. No amount of Fibonacci arithmetic changes this. But the ritual of estimation creates the feeling of control — the sense that the sprint’s capacity has been measured, the work has been weighed, and the commitment is informed.
The feeling is valuable. The precision is fictional.
“Sprint 1: Vector embeddings and similarity computation
Sprint 2: Caching layer and invalidation logic
…
Sprint 8: Performance optimization”
— The Caffeinated Squirrel, proposing eight sprints for a feature that shipped in forty-seven minutes, The Feature That Wasn’t
The Lifelog Alternative
In the lifelog, sprint planning was replaced by pointing at things and saying “do that.”
When AI agents were dispatched into the codebase, the planning process was: look at the backlog, pick the next important thing, brief an agent, move on. No story points. No capacity calculation. No commitment ceremony. The agent returned with a gap analysis or a completed implementation, and the human made the next decision.
Ten tickets per day. No planning meetings. The plan was the work. The work was the plan.
“By the time the Squirrel had opened Jira — sorry, Linear — to create a sprint board, the parser was handling frontmatter that even strict YAML couldn’t parse.”
— The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
The Squirrel was still planning Sprint 1 when the code from Sprint 3 was already in production. The plan was not the bottleneck. The plan was the obstacle.
The Real Sprint Planning
Sprint Planning works when it answers one question: “What is the most important thing to build next?”
It fails when it tries to answer: “How much can we build, measured in imaginary units, committed to publicly, tracked on a chart, and reviewed in a ceremony?”
The first question takes fifteen minutes. The second takes four hours. The sprint does not care which question you answered. The sprint delivers what it delivers, at the pace reality allows, regardless of the Fibonacci number on the ticket.
