Story Points and Reliable Planning In 2026?! Beyond 80%: When Agentic Coding hits mainstream; 4 Hours of Deep work per day?

Issue #80 Bytes

🌱 Dive into Learning-Rich Sundays with groCTO ⤵️

Article of the Week ⭐

“For throughput to be a reliable predictor, one condition must be met: the items being counted need to be roughly similar in size. This doesn’t mean identical, just within the same order of magnitude.” —Andrea Laforgia

From Story Points to Reliable Planning: A Practical Guide for Teams Ready to Stop Guessing

Planning tends to go off the rails when teams mistake numbers for understanding. Story points were supposed to be a thinking tool. In practice, they’ve become a time sink that produces confident-looking numbers and unreliable plans. Teams argue about whether something is a 5 or an 8, then act surprised when the sprint doesn’t land the way the numbers promised.

The uncomfortable part isn’t that story points are imperfect. It’s that teams keep using them even after they’ve stopped helping.

Slicing > Estimates

What changes when teams stop guessing:

• Planning shifts from debate to clarity

• Forecasts come from what gets finished, not what felt reasonable at the time

• The conversation centres on right-sizing, not deadlines

From there, planning starts to feel less like a ritual and more like a decision.

Story points fail for predictable reasons. They mean different things to different people, even on the same team. Velocity gets treated as stable when everyone knows it isn’t. And once those numbers start getting used to judge performance, they quietly inflate. The process grows heavier, but the signal doesn’t improve.

What holds up better is much simpler: counting completed work. Throughput isn’t clever, but it’s at the very least honest and data-driven. It reflects reality instead of aspiration, especially when team members disagree on levels of interpretation or base knowledge.

Teams that look at how many items they usually finish planning starts being useful. When most work fits into one- or two-day chunks, size differences stop dominating the conversation.

This is where many teams hesitate. Slicing that small feels awkward at first. But the discomfort usually comes from framing work as components instead of outcomes. Once the focus moves to something a user can see or react to, thin slices appear more easily than expected.

Planning gets calmer after that. Teams pull work based on what they usually finish. They spend their time checking understanding, surfacing risks, and making sure items are small enough to move. The numbers fade into the background, where they belong.

Predictability doesn’t come from better estimates.
It comes from work that’s small enough to flow.

Other highlights 👇

The 80% Problem in Agentic Coding

AI didn’t stop at helping engineers code faster.
It crossed a line where most of the code now gets written without them.

For some teams, the shift was sudden: from “AI assists my work” to “AI does the work and I supervise.” Output jumped. PRs multiplied. Shipping felt easier than it had in years.

The cost showed up later — not in broken builds, but in understanding.

What changes once agentic coding passes ~80%:

• Errors move from syntax to architecture

• Review effort grows as coding time shrinks

• Code volume increases faster than comprehension

High Volume Agentic Coding Moves Engineering Focus

Teams that struggle treat AI as a faster pair of hands. Teams that succeed redesign their workflow around it. What teams find to work best in practice:

• Define success before execution
  Agents are good at iterating toward a goal. They’re bad at choosing the right one. Clear specs, constraints, and tests matter more than ever.

• Use tests as guardrails, not afterthoughts
  Let agents loop until tests pass. If the same mistake repeats, the fix is a new test.

• Bound autonomy deliberately
  Small tasks. Clear inputs. Explicit stop conditions. Unlimited freedom produces unlimited complexity.

• Review for design, not syntax
  Syntax is cheap now. Architecture, invariants, and intent are not. Reviews should focus there.

• Treat confusion as a signal
  If the team can’t explain how something works, that’s debt. Treat it accordingly.

Agentic coding works best in greenfield systems and small teams, where context is shallow and refactoring is cheap. In large, mature codebases, the bar is higher. The agent doesn’t know the unwritten rules. Someone has to own them.

AI can generate almost unlimited code. The scarce skill now is deciding what deserves to exist and keeping the system understandable once it does.

You can code only 4 hours per day. Here’s why.

Most engineers already feel this limit, they just keep working past it.

After a few hours of real coding, progress turns cosmetic. Still, teams plan around eight-hour days and treat the drop in quality as a personal failure instead of a structural one. The mistake isn’t discipline. It’s designing teams as if deep thinking scales with time.

Ignoring this ceiling quietly creates rework, burnout, and an atmosphere of false urgency.

Let’s focus on baseline:

• Deep coding has a hard cognitive cap, usually 3–4 hours

• Meetings and interruptions consume the best hours, not the leftovers

• AI does not extend focus-time, merely shifts it

• Protecting “depth” over hours is what boosts productivity

Flow

Flow is the real multiplier most teams never plan for.

When developers talk about “good days,” they’re rarely talking about hours logged. They’re talking about the stretches where everything clicks just right. The problem holds still long enough to reason about, decisions stack cleanly, and progress feels almost effortless.

Research has been consistent on this for decades: deep, uninterrupted concentration produces outsized results. For software work, the difference is rather dramatic. The same engineer, working on the same problem, can deliver multiples more value when they’re able to stay immersed long enough for context to fully load.

But flow is very fragile. It requires just enough challenge to stay engaged, just enough clarity to avoid thrashing and, above all, protection from interruption. Most engineers rarely reach it not because they lack skill, but because their day never gives them a fair shot.

The Day

That changes how the day gets designed. Focus blocks stop being “nice to have” and start being non-negotiable. The work entering those blocks becomes sharper. Instead of “working on the backend,” the aim is to produce something concrete enough to finish before context decays.

It also changes when hard problems get tackled. Most developers don’t struggle in the afternoon because they’re lazy; they struggle because their best cognitive hours were spent in meetings. When mornings disappear into syncs and ceremonies, the most demanding work gets pushed into the weakest part of the day. The result looks like low productivity, but it’s really poor allocation.

The teams that consistently do well treat attention as a scarce resource. They batch communication. They cluster meetings. They block time for real work and defend it socially, not just individually. They understand that long, uninterrupted sessions beat heroic late-night pushes every time.

Optimal Flow is about creating the conditions where the brain can actually do what it’s good at. When those conditions exist, three focused hours routinely outperform eight distracted ones. And once teams experience that difference, it becomes obvious why productivity problems rarely get solved by adding more time.

---

When Visibility Becomes the Real Problem

Most engineering teams don’t suffer from a lack of tools. They suffer from a lack of clarity. Work moves fast, data piles up, and yet simple questions remain hard to answer. Where is time actually going? What’s slowing teams down? Which signals can be trusted?

This piece explores why choosing an engineering intelligence platform is less about feature checklists and more about decision-making. It walks through how to think about visibility, signal quality, and trade-offs before committing to any system. If you’ve ever felt that dashboards show activity but not understanding, this is a useful place to start.

---

Find Yourself 🌻

That’s it for Today!

Whether you’re innovating on new projects, staying ahead of tech trends, or taking a strategic pause to recharge, may your day be as impactful and inspiring as your leadership.

See you next week, Ciao 👋

---

Credits 🙏

Curators - Diligently curated by our community members Denis & Varun

Featured Authors - Andrea Laforgia, Addy Osmani, Dr Milan Milanović

Sponsors - This newsletter is sponsored by Typo AI - Engineering Intelligence Platform for the AI Era.

---

1) Subscribe — If you aren’t already, consider becoming a groCTO subscriber.

2) Share — Spread the word amongst fellow Engineering Leaders and CTOs! Your referral empowers & builds our groCTO community.