Beyond Story Points, Finding Flow in Agile
Wednesday, July 16, 2025
11 min read
“The mark of a person who is in control of consciousness is the ability to focus attention at will, to be oblivious to distractions, to concentrate for as long as it takes to achieve a goal, and not longer. And the person who can do this usually enjoys the normal course of everyday life.”
― Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience
Story points continue to be one of the most popular methods of estimation within software development projects, and teams are becoming increasingly sophisticated in their approaches to the activities involved. There is a continuous effort at attempting to hone the skills required to select the most accurate Fibonacci number at the infamous planning poker table. It's quite easy to get ‘lost in the sauce’ so to speak. Complexity mapping, velocity tracking, and highly specialized spreadsheets can feel very productive, but are they actually contributing to the goal?
Remember The Goal
It’s worth re-iterating why we estimate development work in the first place. Understanding and internalizing the goals of estimation is essential to evaluating the activities and some of the arguments presented below.
Capacity Planning
Being able to predict the efforts involved in a project or feature is pertinent information for making some important team oriented decisions. When do we know whether the team is of the correct size? One factor is certainly how capable the team is of delivering outcomes in a timely manner. So being able to estimate the work in development weeks and project that out to an eventual release date can be extremely informative. If the timeline is acceptable, great, but if not it may be necessary to allocate additional resources for hiring or team transfers.
Mapping estimations onto team capacity is a key exercise in order to be able to appropriately allot space on the roadmap to specific work. Figuring out what can be done by team, and on what timeline, allows for effective prioritization of development time. This is especially important for the type of work that development teams really value but might never be a major priority from a business perspective. Sometimes, unfortunately, the only way to address tech debt is to find time in the gaps between product or sustainability work that is driven by external stakeholders. That job becomes much more difficult if the team does not have a good sense of the effort involved in the projects they are committed to, or the tech debt work itself.
Strategic Alignment
Beyond the tactical aspects of planning and resource allocation, accurate and transparent understanding of development effort plays a crucial role in aligning the entire organization strategically. It's about more than just knowing how long something will take; it’s about providing a reliable basis for broader business decisions.
At its core, the goal of estimation (regardless of the technique) should be to provide predictability for organizational decision-making. As an example, when stakeholders are trying to predict whether a particular project or feature can be delivered in a future quarter, they need a solid foundation to answer accurately. Wild guesses and vague promises lead to unreliable delivery, eroding trust and causing disappointment and ultimately poor business outcomes.
Reliable estimation helps enable informed decisions to be made around project priority and scope. Knowing the effort involved in different initiatives allows for a more objective comparison, helping to decide which initiatives will deliver the greatest value with the available resources. It is what moves the conversation from wanting something to be done, to the more productive and actionable considerations of priorities and capacity. When can we realistically deliver this work and what scope adjustments might need to be made?
Finally, estimation serves as a powerful communication tool. It’s a way to align expectations amongst teams, stakeholders, and even customers. While no estimate can be perfect, a shared understanding of the effort involved, even if it's expressed as a range rather than a precise number, fosters transparency and minimizes misunderstandings. It helps manage expectations and encourages more realistic and achievable goals.
Realities Of Story Pointing
Now that we have a foundation for the discussion, we can dive into the ineffectiveness of story points at achieving the stated goals.
Being that story points represent the subjective evaluation of effort based on each developers unique state (ie. knowledge, mood, recent experience) at the time of estimation, there is an inherent arbitrary nature to the scores given. This is hardly a predictable or consistent way of performing estimation. Not to mention that due to this imprecise starting point, story points create environments that are primed to be gamed. Post-vote discussions become more about presenting persuasive arguments, rich with unconfirmed assumptions, instead of collaborative conversations about understanding the work in order to come to a shared agreement on effort each developer understands.
This need for a shared understanding and language leads to the next drawback of story pointing: It creates a lot of extra work. Teams are constantly looking for the formula or correct spreadsheet layout that will allow for mapping new tickets to arbitrary buckets. This is nothing but busy work and is an easy trap door to fall into, leading to nothing but a never-ending stream of new methods of calculation of imprecise numbers that will never actually provide the shared understanding they aim to. The worst part being that all this additional effort does not actually bring you any closer to the original goals either, which is to produce outcomes (not estimations).
This lack of shared understanding and language spreads beyond just the development team. If Product Managers and other stakeholders are consuming the estimates (as they should be), they are also making their own assumptions and interpreting the estimates based on them. Being that many of these stakeholders are also not in the codebase on a frequent basis (in most cases), it is wildly unlikely that they will have the same understanding of the complexity estimates they are reading as the developers who created them. This opens the door to further inefficiencies and wasted effort in the future when the consequences of this misalignment come.
But wait! Story points are used all over the software industry, and teams are still shipping plenty! This is certainly true, but how many teams are shipping high quality, on-time, committed scope projects at high rates of throughput? It’s a very difficult thing to confirm industry-wide, but I would argue very few. High performing teams are thought of such because they produce business outcomes, and for that to happen predictability and accuracy are important. Businesses work in time intervals and story points do not directly map onto timelines, leading to poor predictability and low accuracy. Teams are constantly battling rising tech debt, shrinking scope, and extending delivery times to account for this discrepancy between points and time while trying to meet their business objectives.
None of this translates to high performance or productivity.
There Are Other Options
Before taking a look at some alternatives to story pointing, come with an open mind and understanding that YMMV (Your Mileage May Vary). Each team has a unique makeup and can benefit from some custom tailoring of their estimation techniques. This is far from an exhaustive list of alternatives, and more an opinionated take on methods to try.
Time-Based Estimation
Estimating work in time units (hours, days, weeks) comes with a few key advantages that you should weigh against your current challenges:
Direct and widely comprehensible: Time-based estimation provide a universal language for all involved. Expectations are very clear for developers, and planning conversations become a lot more concrete and understandable by stakeholders. This is particularly important for sequential work, when work items need to be addressed in a particular order. It becomes clearly understood when dependant work is enabled, and when stakeholders can expect work to be actioned, avoiding the classic Slack pings of “when will this be started?”. Making more of your external communication self-serve and predictable is a boon to productivity and focus.
Makes tracking and metrics easier: It becomes easily identifiable when particular work is ahead or behind schedule because we can easily see the time spent against the estimated time. This also allows us to intervene when needed because we now have a clear signal when something is amiss. Tracking progress becomes a simple task instead of a vague assertion, and by tracking progress in this way we can also forecast completion by projecting into the future based on the current rate of progress.
Improved accountability: This is especially pertinent to understand as we enter an industry where AI is expected to increase productivity greatly. A clear goal, which time estimates are, is an effective motivator for improved productivity.
Resourcing: This is simply a point on logistics. If you are looking at hiring or signing contracts for additional temporary help, your estimates and the forecast they can provide help you to make more informed decisions.
If you do decide to try this variation of estimation, some (hopefully) useful advice:
Avoid micromanagement: It’s easy to clock-watch and be constantly on the lookout for work that is crossing it’s estimated time, much more so than indirect estimation methods like Story Points. This is the number one way that time estimation fails, and lowers trust. Trust in your team and their estimates, and be ready to adjust when needed and account for some variability. Keeping track of an “original” estimate along with the actual time spent is a key way to actually leverage this estimation method to improve team process or knowledge, or coach individual developers.
Be honest: Creating accurate time estimates will take experience, and teams cannot be expected to be correct 100% of the time. Make this clear to your team, and ensure that it is understood that cutting corners in the name of achieving the original estimate is much less valuable than what can be learned from an inaccurate estimate. Estimates should be drivers of conversation and collaboration, not anxiety.
(Mostly) No Estimation
The idea with this variation is to time-box work at most, when necessary, and run “spikes” or discovery work in order to break down larger problems. The only actionable work is well understood, small code changes with predictable outcomes, allowing for a constant flow of delivery.
Focusing more on throughput: As a total velocity of delivery, focusing on throughput allows teams to eliminate all the effort spent on creating inherently uncertain estimates, and puts that effort into increasing productivity through focus on technical excellence and strong communication within the team. This is a much more exciting metric for developers, and ultimately more rewarding. Our existing standard measures of productivity (ie. DORA) become focused measures on how to improve various parts of the SDLC implementation that exists within the team.
Delivering value is the priority: Simplifying the process so drastically enables the effective use of tools like Kanban. The focus of items on the board becomes the value of the output, and that is what determines priority alone. Frequent feedback loops become important to remain agile in response to any issues that might arise. Refinement conversations become more practical and useful, without the cruft of dealing with schedules.
This is probably only something achievable only by well-gelled, smaller teams working in well defined, and well structured repositories of code. Providing casual estimates only requires strong communication and active participants with an existing developed trust and transparency.
There are no rules!
It’s worth re-iterating that there are no rules when it comes to this. Although it might feel like certain practices are ubiquitous throughout software development, we are free to find our own way. The true focus should be on understanding and delivering valuable outcomes, not arbitrary numbers.
Was this helpful?
