Team missing deadlines? How to estimate without planning poker
Tired of estimates that never match reality? Learn how to drop planning poker and use continuous flow and batch size to accelerate software deliveries.
Summary
- Traditional hour-based estimates often fail due to the inherent uncertainty of software development
- Continuous flow replaces long forecasts with a steady, predictable rhythm of small value deliveries
- Reducing batch sizes minimizes technical risk and accelerates user feedback cycles
- Tracking cycle time is far more reliable for forecasting than guessing how many hours a task will take
- Limiting work in progress prevents bottlenecks and keeps the team focused on finishing rather than starting
Why planning poker fails in modern engineering
Who hasn't spent hours debating whether a task is worth two or three story points in an exhausting meeting? This ritual, known as planning poker, tries to turn uncertainty into mathematical exactness, but it rarely works in practice. In software engineering, predicting the exact future of a line of code is almost impossible because unforeseen issues, hidden bugs, or external dependencies always arise.
When a team spends more time estimating than building, the process loses its purpose and deadlines keep slipping. The root of the problem isn't the team's inability to guess numbers, but the very premise that complex estimates create predictability. To improve this scenario, we need to look at how work actually moves through the team, something we frequently discuss when optimizing processes for repetitive terminal tasks using Makefiles to gain operational agility.
The power of continuous flow in software delivery
Continuous flow is an approach that treats development like a river flowing at a steady speed, instead of a series of dams and floodgates called sprints. Instead of accumulating a bunch of features to launch all at once, the team delivers value in small daily chunks. This reduces the psychological pressure of grandiose deadlines and drastically dampens the impact of bugs, since an issue affects only a tiny slice of the system.
In practice, this means the software is always ready to go live, and developers focus on finishing what they started before pulling in new demands. This profound mindset shift transforms engineering into a smooth, predictable assembly line, eliminating the need to guess distant deadlines because the planning horizon shrinks to days or hours.
How batch size dictates your team velocity
Batch size is the amount of work you package and send all at once to production. Think about doing laundry: if you wait to accumulate dirty clothes for a whole month, you will need a giant washing machine and a lot of time to fold everything, running the risk of not having your favorite shirt when you need it. In development, large batches generate massive pull requests that take days for other programmers to review, stalling the entire team's flow.
When we reduce the batch size to tiny changes, code review happens in minutes and the risk of merge conflicts plummets. Code reaches users faster, and any failure is caught immediately. This strategy of slicing deliveries echoes the logic of applying real code splitting to heavy React bundles to load only what is necessary on the user's screen, optimizing resources and speed.
Replacing guesswork with cycle time metrics
If we stop using planning poker, how do we know when a feature will be ready? The answer lies in measuring the past to understand the future, using real data instead of optimistic guesses. Cycle time measures exactly how many days or hours a task takes from the moment a programmer starts writing code until the moment it reaches production.
By analyzing recent history, the team can state with high statistical probability that ninety percent of tasks take up to four days to complete. This statistical approach, based on real delivery data, is far more honest with stakeholders than promising a magical date pulled out of a hat. The focus shifts to shortening this cycle time through automation and the elimination of unnecessary bureaucracy.
Limiting work in progress to unblock deadlines
There is a popular saying in engineering that sums it all up: stop starting and start finishing. When we allow developers to open five tasks at the same time, attention fragments, context-switching overhead explodes, and nothing truly moves forward. Strictly limiting work in progress forces the team to cooperate to solve impediments and finish what is already on the table.
If a peer is stuck on a complex database problem, for example, the best way to help isn't to open a new demand, but rather to unblock the peer so the flow doesn't stop. This collaboration drastically reduces idle task time and ensures deadlines are met naturally, without stressful status-meeting pressures. To explore these architectural concepts further in production, see our related technical analysis on Slow vector database? How to manage embeddings.
Conclusion
Dropping planning poker and embracing continuous flow with smaller batches is not just a tool change, but an evolution in software engineering mindset. By slicing deliveries, measuring real cycle time, and limiting simultaneous work, teams regain predictability and daily sanity. Delivering with consistency matters much more than trying to guess impossible deadlines in the dark.
Instead of wasting precious energy debating abstract points, invest in simplifying your processes, automating repetitive chores, and keeping the code flow moving without barriers. Deadlines will cease to be a source of anxiety and will become a natural consequence of a healthy, efficient development system.