Plan Less, Build More

Building software is an act of discovery. Software has essentially zero marginal cost: once a solution exists, copying it is free. That means writing code is solving an unsolved problem, at least locally. Another truism is that discovery isn't just a phase of software development, it's the definition of it. Yet the "standard" way we build software as an industry, (especially under Scrum), is to split the discovery from the implementation. This usually takes the form of gathering requirements, writing the spec, & estimating effort then some kind of a waiting period before the ticket is moved from the backlog into a sprint. The argument of this post is simple: the real effort in building software was never the implementation of a clear plan. It was always the figuring out & I'm tired of pretending otherwise.

The problem that planning & backlog grooming attempt to solve is one of coordinating multiple teammates & reducing rework. As in, we can build the bridge from both sides if we agree where they are going to meet. That's a real challenge so this post does not advocate for never planning anything. Deciding what to build, talking to users, killing bad ideas before anyone writes code, is real work that genuinely can happen ahead of time. My target is the planning that tries to pre-solve how the thing gets built, before anyone has opened the codebase. We tend not to track that work the way we track implementation, giving the impression that it is somehow free. A one hour backlog grooming that stretches to three, or a 2 point issue that takes five days due to untracked requirements: both are telling us the same thing. Technical discovery is the important, costly work. It isn't a side activity we can confine to an hour on Tuesdays & the occasional research spike. It's most of the job, the typing was always the easy part.

If the ceremony isn't buying us predictability, what would we do instead? Start by admitting what every retro already knows: software development is expedition work, not assembly work & the best thing we can do as leaders is to optimize the fuck around, find out cycle. There is no amount of planning that turns "figure out something nobody has figured out" into a process with a reliable schedule, & twenty years of sprint velocity charts have not changed that. So stop splitting the work in two. The current model has one group figure out what to build & write it down, then has someone else build it later, with all the context loss that "later" implies. But the figuring out & the building were never separable, & every artifact we produce to bridge the gap, the detailed issue, the estimate, is a cost we pay to maintain a split that benefits no one. Do the discovery & the build as one motion, by the same person, & most of that cost simply disappears.

In my experience, task trackers like Jira or Linear work best as a shared todo list. The ideal issues are two to five sentences, name the problem or describe the end state & leave the rest for implementation. Anyone on the team can write one, & if real product discovery happened, its home is a more durable document than a Jira ticket anyway. The author of the task gets to stay in their flow state & the person picking up the task gets to solve the problem that best fits the current state of things. The same goes for detailed estimation. Debating whether something is a 3 or a 5 is a ritual dressed up as rigour, & the estimate will be wrong in exactly the ways that matter. Write down what needs to be true when the work is done, hand it to someone (possibly your future self) with the context & trust to figure out the rest. We can then all spend the reclaimed hours actually building.

That handoff only works if it happens soon, though. Issues age like milk, the codebase moves on, the assumptions baked into the description quietly expire, & the context that lived in the author's head at writing time evaporates entirely. A backlog of three hundred carefully groomed issues isn't an asset, it's a museum of things we once believed. This is the cruel irony of detailed upfront specification: the more time you pour into an issue, the more you lose when it inevitably goes stale. A two sentence issue that dies in the backlog cost you two sentences.

So here we are: developers estimate their work, break it into points, track it in sprints & explain the variance in retros. The planning apparatus around them, the grooming sessions, the refinement meetings, the estimation debates, is subject to none of that scrutiny. Nobody story points the backlog grooming. Nobody runs a retro on why refinement ran double its timebox. I don't think anyone designed it this way, & I don't think PMs are dodging an audit. The desire underneath it all, to estimate, to track, to make delivery predictable, is completely reasonable. But we've built a system that measures the cheap, visible half of the work & leaves the expensive half invisible, & now everyone is trapped inside it. The developer can't skip estimation, the PM can't cancel the ceremonies, & nobody individually has the influence to, or wants to take the risk of, changing a process that arrived as industry best practice. If we had tracked the whole effort honestly, planning included, Scrum would never have become the industry standard it is today.

To be clear, none of this makes the business's question go away. Sales still promised a date, the launch is still on the calendar, & "it's done when it's done" is not an answer anyone can take to a customer. But here's the thing about that date: it was always a guess. Three hours of planning poker doesn't change that, it just laminates the guess so it looks like a commitment. If the estimate is going to be a guess either way, make it in five minutes, then spend the three hours you just saved actually building. A team that starts sooner & builds more hits more deadlines than a team that estimates beautifully. The way to serve the business isn't better guessing, it's needing to guess less.

Going into Monday's grooming session & flipping the table isn't going to get you anywhere. The coordination problem is real, some planning will always earn its keep, & each team's process is their business. But most of us inherited the way we work. It arrived pre-installed from a CTO who has run it since they were a junior developer, or an EM who got certified in it fifteen years ago, & it has survived ever since on the strength of never being questioned. So the next time writing a Jira item or estimating an issue eats 30 minutes of your day, maybe just notice it. Notice where the effort actually went, & whether the process acknowledged that effort or hid it. That's it.

The work was never predictable, & no amount of ceremony has changed that. The teams that admit it get to spend the difference building software.