Velocity Is Not Delivery: Why AI Makes Effort-Based Planning Absurd

This is the sixth article in my series exploring how AI is quietly dismantling long-held assumptions in the Software Development Life Cycle.

The earlier pieces examined how code is no longer the primary unit of value, why cheap AI-generated code can become strategically expensive, how software is entering a post-human-author era, why traceability is no longer linear, and why clean code is no longer enough when context drifts. The common thread is simple: AI is not merely accelerating software delivery. It is changing where delivery risk lives.

This article takes on Assumption #5:

Assumption #5: Effort predicts delivery. Really?

For decades, software planning has rested on a rough but useful belief:

More effort means more output. More completed stories mean more progress. Higher velocity means the team is doing better.

It was never perfectly true. But it was useful enough. Why?

Because software creation was expensive. Human effort was the visible constraint. Developers had to write the code, wire the integrations, build the screens, fix the defects, and prepare the release. So it made sense to estimate work in story points, engineering days, team capacity, or sprint velocity.

These were not perfect measures of value. They were proxies. AI exposes the proxy.

The old math is breaking

In the pre-AI world, effort and output had a visible relationship.

A story requiring more logic, more screens, more tests, or more integration usually needed more engineering time. Estimation was imperfect, but the correlation was defensible.

AI-assisted development weakens that relationship.

A developer can now generate a service, write test cases, refactor modules, create documentation, produce boilerplate, and explore implementation options in a fraction of the time it previously took.

That is not speculation anymore.

GitHub’s controlled study found that developers using Copilot completed a coding task 55.8% faster than those without it. McKinsey found that generative AI could help developers complete some coding tasks up to twice as fast, especially in areas such as code generation, refactoring, and documentation. (arXiv) (McKinsey & Company)

So yes, AI can improve coding speed.

But that is exactly where the planning trap begins.

Because software delivery is not the same as software generation.

Velocity can now lie faster

The most dangerous thing about AI-assisted delivery is not that teams may move slowly. It is that they may look fast.

More stories closed. More pull requests merged. More code generated. More tests written. More demos produced. More dashboards turning green.

Wonderful.

Now ask the uncomfortable question:

Did the completed work move the business objective it was meant to move?

That is where many delivery models start to wobble.

A sprint board can show progress while the business remains unchanged. A team can complete every story and still fail to reduce onboarding drop-offs, improve claim settlement time, increase straight-through processing, reduce manual operations, or improve customer adoption.

The team was busy. The system changed. The business did not.

That is not delivery. That is decorated motion.

The issue is not Agile. The issue is lazy measurement.

This is not an argument against Agile.

Agile, when practiced seriously, was never meant to be a factory for story-point inflation. It was meant to improve feedback, adaptation, and customer value.

But in many organizations, velocity quietly became a management comfort blanket.

“How many points did we complete?” “How much capacity do we have?” “Can we increase throughput next quarter?” “Why did this team deliver fewer stories than that team?”

These questions are not useless. They are just incomplete.

In AI-assisted delivery, they can become actively misleading.

Because AI reduces the cost of producing implementation artifacts. Once that happens, the old completion metrics become easier to inflate and harder to trust.

The team may not be gaming the system. The system may be gaming the team.

The story is not done when engineering finishes it

Let us take a simple banking example.

A team is asked to improve digital customer onboarding.

One story says:

“As a customer, I want to upload KYC documents digitally so that I do not have to visit a branch.”

In a traditional model, this story may be estimated, designed, built, tested, accepted, and closed.

Engineering definition of done:

The upload works. The file types are validated. The API stores the document. The workflow updates the status. The tests pass.

Product definition of done:

The journey is usable. The customer understands what to upload. The screen is clear. The drop-off points are reduced. The experience works on mobile.

Business definition of done:

Onboarding cycle time improves. Manual operations reduce. Compliance exceptions reduce. Branch dependency drops. More customers complete onboarding without assistance. The cost-to-serve comes down.

These are not the same definition.

That distinction mattered earlier too. But AI makes it critical.

Because now the engineering implementation can arrive very quickly. The upload flow can be generated. The validation logic can be drafted. The backend API can be scaffolded. The test cases can be produced. Even the documentation can be written.

The story can look complete before the organization has proved that it matters.

That is the new risk.

The new metric: Business Objective Delivered

In AI-assisted delivery, story completion should no longer be treated as the primary signal of progress.

The stronger question is:

What business objective was this story meant to move, and did it move?

This requires a different discipline.

Every meaningful story should carry a business objective. Not a vague one. A measurable one.

Not:

“Improve onboarding experience.”

But:

“Reduce assisted onboarding cases by 20% in the target segment.”

Not:

“Automate claims review.”

But:

“Reduce manual claim triage effort by 30% while maintaining exception accuracy and auditability.”

Not:

“Build a trading analytics dashboard.”

But:

“Reduce analyst investigation time for defined scenarios without weakening data lineage or model explainability.”

The metric is not just completion.

The metric is Business Objective Delivered.

And where the objective is not fully delivered, the team should understand the Business Objective Deviation.

What did we expect to move? What actually moved? What did not move? Why? Was the story wrong, the workflow wrong, the adoption weak, the data poor, the integration incomplete, or the assumption flawed?

That is a much better executive conversation than asking why a team delivered 48 points instead of 52.

Engineering must shift left — properly this time

For years, “shift left” often meant moving testing, security, or quality earlier in the lifecycle.

That still matters.

But AI forces a deeper shift left.

Engineering must now move into problem selection itself.

Not because engineers should replace business leaders or product managers.

They should not. Nobody needs a steering committee where everyone is armed with Jira and nobody has a customer.

But engineering can no longer wait politely downstream for requirements to arrive.

Because the feasibility of a business idea now depends on questions that are deeply technical:

Is the data available? Is the integration surface sane? Can this behavior be verified? Can the decision be explained? Can the workflow survive exceptions? Can operations handle the edge cases? Can compliance audit the outcome? Can the system be observed after release? Can the context be kept synchronized as the system evolves?

These questions are not “technical details.”

They are business delivery risks.

Earlier, organizations could afford to separate business definition, product shaping, engineering delivery, and operational readiness into sequential stages.

AI makes that separation expensive.

When implementation becomes faster, bad problem selection becomes more dangerous.

You can now build the wrong thing at impressive speed.

Congratulations. The waste is agile now.

Business, product, and engineering evaluation must happen together

In the old model, the flow often looked like this:

Business defines the need. Product writes the stories. Engineering estimates and builds. QA validates. Operations receives. Users react.

This model already had problems.

AI makes those problems louder.

The new model must be more simultaneous.

Business must define the outcome. Product must define the behavior change. Engineering must define the system reality. Architecture must define the constraints. Risk must define the guardrails. Operations must define runnability. Data teams must define what can actually be known. Users must validate whether the workflow makes sense.

This does not mean every story needs a village procession.

It means important stories cannot be treated as engineering tickets with business labels attached.

Stories are business bets expressed through software.

Now those bets can be implemented faster than they can be understood.

That is the danger.

The verification burden moves to the center

The DORA 2024 research is useful here because it complicates the easy narrative. It found that AI adoption was associated with increases in individual productivity, flow, and job satisfaction, but also with negative impacts on software delivery stability and throughput. Google Cloud’s summary reported an estimated 1.5% decrease in delivery throughput and 7.2% reduction in delivery stability as AI adoption increased. (Dora) (Google Cloud)

That does not mean AI is bad for delivery.

It means individual productivity and software delivery performance are not the same thing.

That distinction is the heart of this article.

A developer may move faster. A team may generate more. A backlog may shrink. A release may contain more change.

But enterprise delivery depends on whether the system remains stable, usable, secure, compliant, integrated, observable, and aligned to the business objective.

The bottleneck moves from effort to confidence.

Confidence that the right problem was selected. Confidence that the generated solution fits the enterprise architecture. Confidence that the workflow will be adopted. Confidence that integration will not create downstream fragility. Confidence that the behavior can be tested and explained. Confidence that the business metric will move. Confidence that the system can be operated after the demo glow fades.

This is where the real work goes.

AI does not remove effort.  It relocates it.

A second example: claims automation

Consider insurance claims.

AI can help generate a claims intake workflow quickly. It can draft validation logic, triage rules, customer communication templates, fraud indicators, and exception queues.

The visible delivery may move fast.

But the real business objective is not “launch claims automation.”

The objective may be:

Reduce claim settlement time for low-risk claims while preserving fairness, explainability, and escalation quality.

That is a very different delivery problem.

Now the relevant questions become:

Are the triage rules explainable? Are vulnerable customers treated fairly? Are exceptions routed correctly? Can claims handlers override the recommendation? Can regulators inspect the decision path? Does automation reduce cycle time without increasing dispute rates? Do customers trust the outcome?

The code may be easy. The confidence is not.

A third example: trading analytics

Or take trading analytics.

AI can generate dashboards, anomaly detectors, natural-language query interfaces, and alerting workflows quickly.

But the business objective is not “build analytics.”

The objective may be:

Reduce investigation time for defined risk scenarios while preserving data lineage, latency discipline, and decision accountability.

Again, the engineering artifact is only part of delivery.

The harder questions are:

Where did the data come from? How stale is it? Which assumptions shaped the alert? Can analysts reproduce the result? What happens when the model is wrong? Who is accountable for the decision? Can the system explain itself under pressure?

No serious CXO wants faster dashboards if the organization gets faster confusion.

What should replace effort-based planning?

Not another grand framework.

We have enough frameworks. Some of them are now holding hands in PowerPoint and blocking the exits.

But we do need a better planning conversation.

Instead of asking only:

“How much effort will this take?”

Leaders should also ask:

“What confidence must we earn before this is considered delivered?”

That confidence has several dimensions:

1. Business confidence Does the story clearly map to a measurable business objective?

2. Product confidence Will the user or operator actually change behavior because of this?

3. Engineering confidence Can the solution be integrated, tested, scaled, and maintained?

4. Data confidence Is the required data available, reliable, timely, and governed?

5. Operational confidence Can the business run this under real-world exceptions?

6. Risk confidence Can the behavior be explained, audited, secured, and controlled?

7. Context confidence Will intent, design, code, tests, decisions, and runtime behavior remain synchronized over time?

This is not about replacing delivery with bureaucracy.

It is about preventing speed from becoming a liability.

The Business Definition of Done

The traditional definition of done usually asks whether the story has met its acceptance criteria.

That is necessary. It is no longer sufficient.

AI-assisted delivery needs a Business Definition of Done.

A meaningful story should define:

What business objective does this support? Which metric should move? What user or operational behavior should change? What evidence will prove that the change worked? What deviation is acceptable? What will we do if the metric does not move? What risks must remain within tolerance? What must be observable after release?

This changes the delivery conversation.

A story is not done when code is merged.

It is not done when QA signs off.

It is not done when the product owner accepts it.

It is not even done when it is deployed.

A story is done when the organization can say one of three things:

The intended business objective moved. The objective did not move, and we know why. The objective itself was wrong, and we have learned enough to change direction.

That is delivery.

Everything else is activity with better lighting.

What this means for CXOs

For CXOs, the implication is uncomfortable but useful.

AI will make many teams appear more productive before the enterprise becomes more effective.

That gap is where money will be wasted.

The wrong response is to ask engineering teams to generate more code with fewer people and call it transformation.

That is spreadsheet courage.

The better response is to redesign delivery governance around outcomes, confidence, and learning.

This means:

Stop treating velocity as a proxy for value. Stop rewarding completion without outcome movement. Stop separating business definition from engineering reality. Stop measuring AI impact only through developer productivity. Stop assuming that faster implementation means faster enterprise change.

The strategic question is no longer:

Can we deliver more stories?

It is:

Can we select better problems, implement them faster, verify them harder, and learn from them sooner?

That is where AI becomes useful.

Not as a typing assistant. As a forcing function for better delivery discipline.

The uncomfortable conclusion

Effort-based planning made sense when effort was the visible constraint.

AI changes that.

When coding effort falls, ambiguity becomes more expensive. When output increases, verification becomes more important. When stories move faster, business alignment must become tighter. When teams generate more, leaders must ask harder questions about value.

Velocity is not dead.

But velocity without business confidence is just a faster treadmill.

And in the AI-assisted SDLC, effort no longer predicts delivery.

Confidence does.

A question worth asking

What would change in your delivery model if every story had to declare the business objective it was meant to move — and report deviation from that objective after release?

The complete Series:

· Starting Blog: Breaking the 6 Assumptions of the SDLC

· # 1: Why “Cheap” AI Code is an “Expensive” Strategic Trap

· # 2: The Ghost in the Code—Software’s Post Human-Author Era

· # 3: Traceability is linear and orderly

· # 4: Human readable code guarantees maintainability

· # 5: Effort predicts delivery

· # 6: Quality Engineering exists primarily to catch human mistakes

#ThinkInsideTheBox, #EnterpriseAI, #AIArchitecture, #SoftwareEngineering, #DigitalTransformation, #EngineeringLeadership, #ResponsibleAI, #ProductManagement

 

Further reading

1. Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. — “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot” A controlled study found that developers using GitHub Copilot completed a programming task 55.8% faster than those without it.

2. McKinsey & Company — “Unleashing developer productivity with generative AI” McKinsey reports that generative AI can help developers complete some coding tasks up to twice as fast, especially in code generation, refactoring, and documentation.

3. Google Cloud / DORA — “Announcing the 2024 DORA Report” The 2024 DORA research found that AI adoption was associated with individual productivity gains, but also with an estimated 1.5% decrease in delivery throughput and 7.2% reduction in delivery stability.

4. DORA — “Accelerate State of DevOps Report 2024”The full DORA report expands on the trade-off: AI adoption improves individual productivity, flow, and job satisfaction, but can negatively affect delivery stability and throughput when engineering fundamentals weaken.