Skip to main content

From Story Points to Decision Throughput

I was in planning recently when someone asked, "How many points can we commit to next sprint?"


For years, that question was normal. Useful, even. It gave us a shared language for forecasting effort and balancing load.


This time it landed differently.


We had engineers delivering implementation work faster than ever with AI support, but our most important initiatives were still bottlenecked. Not by coding capacity. By unresolved decisions about scope, ownership boundaries, quality bars, and integration contracts.


That is when it became clear to me: if execution is getting cheaper, story points are becoming less informative about delivery risk.


I do not think points are useless. I do think they are no longer the primary signal leaders should optimize.




The Bottleneck Has Moved

In a traditional model, writing and refining code consumed most of the schedule. Estimating production effort gave leaders a reasonable proxy for planning confidence.


AI changes that equation.


Now teams can produce implementation options quickly. The hard part is choosing the right option under uncertainty, aligning cross-functional constraints, and revising assumptions without thrash. Those are decision system problems.


When decision quality is weak, high output only accelerates rework.


When decision latency is high, teams idle despite having execution capacity.


Either way, points do not tell the full story.

What I Mean by Decision Throughput

Decision throughput is the rate at which an organization makes and validates consequential decisions with enough quality to reduce uncertainty and move work forward.


I focus on three dimensions:


  • Latency: how long critical decisions wait unresolved.

  • Quality: how often decisions hold up without avoidable reversal.

  • Distribution: whether decision-making capability is concentrated in a few people or spread across teams.


High decision throughput does not mean "decide fast at all costs." It means the organization can convert ambiguity into aligned action without excessive delay or expensive correction.


This is now a better predictor of delivery performance than a single estimate unit.

Where Story Points Still Help (and Where They Mislead)

I still find points useful for local team workload calibration on well-understood work. They can surface overcommitment patterns and support healthier sprint shaping.


But they mislead when leaders use them for:


  • Strategic forecast certainty in ambiguous initiatives.

  • Cross-team comparisons of productivity.

  • Performance interpretation in AI-assisted workflows.


If one team closes more points because implementation is increasingly automated, that does not automatically mean better organizational outcomes. It may simply mean they received cleaner decisions upstream.


Points are a local planning aid. They are not an enterprise leadership compass.

How to Operationalize the Shift

I have started introducing decision throughput into planning discussions with a lightweight approach.


Track decision queues. What material decisions are currently blocking progress? How old are they? Who owns resolution?


Classify reversals. Which reversals were healthy learning and which were avoidable due to weak framing or missing stakeholders?


Measure dependency wait time. How much delivery time is consumed waiting for answers from adjacent teams?


Audit decision clarity. Can teams restate the "why" behind major calls one month later?


When we added these lenses, we found a pattern quickly: our biggest delays were not implementation estimation errors. They were unresolved interface contracts and late policy decisions that nobody owned explicitly.


Once visible, these were fixable.

Leadership Implications

Shifting from points to decision throughput has changed how I evaluate managers and leadership forums.


I now look for managers who:


  • Reduce ambiguity early rather than heroically absorbing ambiguity late.

  • Create fast, inclusive decision loops across functions.

  • Establish clear ownership for high-impact calls.

  • Build team judgment so decisions do not bottleneck on one expert.


That is a different profile than "best sprint planner," and it aligns better with where value is created now.


It also changes staffing conversations. If your organization cannot make high-quality decisions quickly, adding engineers may increase activity but not outcomes.


In that case, the highest-leverage hire might not be an additional implementer. It might be someone who improves architectural governance, product framing, or program integration.

A Better Planning Question

I still expect teams to plan carefully. I still care about commitment discipline. But in an AI-assisted environment, I am asking a different lead question:


What is limiting our decision throughput right now?


That question surfaces more truth than "How many points can we do?"


Because if decisions are stuck, points will not save the quarter.


And if decisions are strong, teams usually find ways to deliver.


So for engineering leaders, maybe the challenge is this:


Are we still managing the bottleneck we used to have?


What would our planning rhythm look like if we optimized for decision quality and latency as intentionally as we once optimized for velocity?


And what outcomes might change if every leadership review treated unresolved decisions as first-class delivery risk?
Labels:

Comments

Post a Comment

Popular posts from this blog

The "Just-in-Time" Manager and the 1:1 Gemini Gem

  We’ve all been there. The calendar notification pings. You finish your previous meeting (which ran over by three minutes), and as the Zoom window for your next 1:1 pops up, you’re frantically tabbing through Google Docs and Slack. You’re trying to remember: What did we talk about last time? Did that project go okay? Wait, did they mention a vacation or a baby? You’re "prepping" while the meeting is already happening. You’re physically present, but mentally, you’re a detective trying to solve the mystery of your own calendar and trying to switch off the last meeting.  It’s a common trap for managers, especially as their direct reports grow and they now have skip level 1-1s, or skip-skip level 1-1s. Our schedules are a mosaic of context-switching, and unfortunately, the deep, reflective prep our direct reports deserve is often the first thing to get squeezed out as we are dealing with incidents or other emergencies.  From "Zero Prep" to "Instant Context" R...
Post a Comment
Read more

Are Engineering Managers Obsolete in an AI World?

So far in my career, our value as leaders was measured by how well we manage the machine - optimizing for velocity, smoothing out team dynamics, and ensuring predictable delivery of business goals. Now, the engine of that machine is changing. For the past few months a part of me is feeling some existential dread - with AI advancing so quickly the fundamental engine of the machine is changing. A lot of the discussion has been on 10x or 100x engineers, but what is this going to mean for Engineering Managers? Do we still need the role? If we do, what does an Engineering Manager in the future look like? The future - maybe I mean now…  I think it's too early to declare the death of the manager but I am ready to place a few definitive bets on changes that are coming.  Firstly Engineering Managers who don’t stay on top of AI developments will become obsolete. The 'wait and see' approach has become a 'wait and become obsolete' strategy. Within a performance cycle or two I p...
Post a Comment
Read more

Prompting AI Adoption for Skeptical Engineers

We’ve all seen the headlines. "AI will replace the junior engineer”.  "The 10x engineer is now a 100x engineer." In leadership meetings almost every conversation comes back to velocity and how we could unlock efficiency with AI.  But when you talk with the team the reality can be different. Your most senior engineers - the ones who built the core of your system - are looking at Copilot or Cursor with a squint. Some see it as a toy; others see it as a threat to the craft; a few see it as a glorified Clippy that hallucinates half-baked solutions into their carefully maintained repos. As Engineering Managers and Directors, we are currently in a delicate spot. We are being asked by the business to "leverage AI," but we are being told by some of our best people that it’s "not quite there yet". How do we advocate for AI without sounding like a marketing brochure? How do we move the skeptics without losing their trust? 1. Validate the Skepticism (Because it...
Post a Comment
Read more