Beyond Scrum: Why AI-Native Engineering Needs Outcome Boards, Not Story Boards

Beyond Scrum: Why AI-Native Engineering Needs Outcome Boards, Not Story Boards

From User Stories to Intent, From Manual Status Reporting to Automated Evidence, and From Managing Activities to Managing Outcomes

By Mark Kendall

Intent-Driven Engineering | Repogenic

Software development is not dead. Agile is not dead. And Scrum deserves considerable credit for helping an entire generation of software teams organize, collaborate, and deliver.

But artificial intelligence is changing the economics, speed, and mechanics of software engineering.

And that raises an important question:

If AI is transforming how software gets built, shouldn’t we reconsider how software engineering gets managed?

For decades, we’ve organized software development around backlogs, epics, user stories, sprint planning, daily standups, and boards that track work moving from one column to another.

These mechanisms served a purpose. They helped people coordinate work when implementation was largely human-driven, progress was difficult to observe, and delivery followed relatively predictable development cycles.

But we’re entering a different engineering environment.

AI can now participate in requirements analysis, system design, implementation, testing, debugging, documentation, and validation.

Engineering teams increasingly work alongside AI capabilities that can execute substantial portions of the development lifecycle.

Yet we continue managing much of this work through the same structures designed for traditional human development teams.

Perhaps it’s time to evolve Agile itself.

Not by inventing another collection of ceremonies.

But by changing the fundamental unit of engineering management.

1. The Problem Isn’t Scrum. It’s What We’re Measuring.

Consider the traditional Scrum board.

TO DO → IN PROGRESS → TESTING → DONE

What does that board actually tell us?

It tells us where work items are located within a workflow.

A user story moves into development.

A task moves into testing.

A feature moves into Done.

But what did the organization accomplish?

Did customer satisfaction improve?

Did transaction processing become faster?

Did the system become more reliable?

Did operating costs decrease?

Did we solve the problem that justified the investment?

A completed story doesn’t necessarily answer those questions.

Neither does a completed epic.

These are useful organizational constructs, but they are not inherently measurements of business value.

Completing work is not the same as achieving an outcome.

That distinction becomes increasingly important in the age of AI.

If AI dramatically accelerates implementation, then tracking the volume of engineering activity becomes even less meaningful as an indicator of success.

We need to measure something different.

2. Replace Scrum Boards with Outcome Boards

I propose a different engineering management model:

The Outcome Board — powered by Intent-Driven Engineering.

Instead of organizing engineering management around individual stories and tasks, organize it around measurable outcomes.

Imagine opening a project dashboard and seeing:

Business Outcome

Engineering Intent

Evidence

Status

Reduce API latency by 30%

INT-001

Performance benchmarks

Validating

Automate supplier onboarding

INT-002

Security and compliance results

Blocked

Improve deployment reliability

INT-003

CI/CD and deployment evidence

Executing

Reduce cloud costs by 20%

INT-004

Cloud cost measurements

Accepted

This board answers fundamentally different questions.

What outcomes are we pursuing?

What engineering intentions support those outcomes?

What evidence demonstrates progress?

What decisions require human attention?

And most importantly:

Are we actually achieving what we set out to accomplish?

The Outcome Board is not simply a redesigned Kanban board.

It represents a different relationship between engineering execution and management visibility.

The outcome becomes the unit of management.

Intent becomes the unit of engineering direction.

Evidence becomes the basis for determining progress.

3. Replace User Stories with Engineering Intent

Traditional Agile teams describe work through user stories.

A familiar example:

As a user, I want a faster search experience so that I can find information more quickly.

That description expresses a legitimate user need.

But it doesn’t necessarily establish the measurable result, engineering boundaries, or evidence required to determine success.

Intent-Driven Engineering approaches the problem differently.

An engineering intent identifies four essential elements:

Intent: What outcome are we trying to achieve?

Inputs and Context: What information and constraints are necessary?

Outputs: What must the engineering system produce?

Success Criteria: What measurable evidence will establish that the outcome was achieved?

For example:

Intent: Reduce search response latency by 30% without compromising security, accuracy, or system availability.

The engineering team now has a measurable destination.

AI can help explore implementation alternatives, generate code, execute tests, and evaluate results.

The human engineering lead retains responsibility for engineering boundaries, consequential decisions, and final acceptance.

We don’t necessarily need to prescribe every implementation step in advance.

We need to define the desired outcome clearly enough for engineering work to proceed responsibly.

This is the foundation of Progressive Intent.

Start with the minimum sufficient intent.

Allow implementation decisions to emerge through engineering execution.

Refine the intent when actual evidence reveals a gap, constraint, or necessary change.

The objective is not to generate increasingly elaborate specifications.

It is to produce successful engineering outcomes with the minimum necessary complexity.

4. The Bigger Change: Stop Manually Reporting Engineering Progress

This may be the most consequential part of the proposal.

Consider what happens in a modern software repository.

Developers and AI agents create implementation changes.

Source control records commits.

Pull requests document proposed changes and reviews.

CI/CD pipelines execute automated tests.

Security tools evaluate vulnerabilities.

Deployment pipelines record releases.

Observability platforms capture operational behavior.

The engineering environment already produces a considerable amount of evidence about what is happening.

Yet many organizations still require engineers to enter much of that information into a separate project management system.

We build software in one environment and manually report progress in another.

Why?

What if the engineering system could produce its own management information?

What if the repository itself became an active participant in engineering management?

Not by generating more reports for people to maintain.

But by automatically publishing verified engineering evidence.

The Repository Becomes the Reporting Engine

Imagine the following sequence.

A human engineering lead defines a business outcome.

An associated engineering intent is approved and registered.

The intent lives in the repository alongside the engineering work.

Implementation begins.

Source control events and execution records identify the active change.

Automated tests execute.

CI/CD publishes the results.

Security and policy checks run.

The Outcome Board updates automatically.

No engineer needs to open another application simply to move a card from one column to another.

The management system receives evidence directly from the systems performing the work.

The board is generated from engineering reality rather than manually maintained descriptions of engineering activity.

There is an important distinction here.

The repository can establish that a test passed.

It cannot automatically establish that the business achieved its desired result.

Those are different forms of evidence.

A trustworthy Outcome Board must understand that distinction.

5. Separate Engineering Completion from Business Success

Suppose the objective is to reduce API latency by 30%.

An AI-enabled engineering team modifies the implementation.

All automated tests pass.

The pull request is approved.

The deployment succeeds.

Traditional project reporting might declare the work complete.

But what happens if production latency improves by only 8%?

The implementation was delivered successfully.

The desired business outcome was not achieved.

Our Outcome Board should report exactly that.

This requires separating engineering execution, validation, acceptance, delivery, and realized results.

A practical lifecycle might look like this:

INTENT → EXECUTING → VALIDATING → ACCEPTED → DELIVERED → OUTCOME VERIFIED

Additional conditions identify exceptions:

BLOCKED: A dependency or human decision prevents progress.

FAILED VALIDATION: Evidence does not satisfy the established acceptance criteria.

These states should be derived from verified events wherever possible.

And an outcome should not be marked successful merely because code has been merged or deployed.

Success requires the appropriate evidence.

6. One Outcome Board, Multiple Repositories

Enterprise engineering introduces another challenge.

A single business outcome may require changes across many repositories and teams.

Consider supplier onboarding.

Achieving the desired outcome might involve an identity service, integration APIs, security validation, a user interface, and several external systems.

Should every repository maintain a separate project board?

Should every team manually report progress into a central management application?

I propose a simpler structure.

Enterprise Portfolio → Project Outcome Boards → Repository Intents and Evidence

The enterprise portfolio identifies strategic objectives.

Each project Outcome Board manages its measurable outcomes.

Individual repositories contain the engineering intents, implementation artifacts, and supporting evidence.

A single outcome may connect to multiple repositories.

A single repository may contribute to multiple outcomes.

The relationship is explicit.

The reporting is automated.

A human engineering lead can see whether the complete outcome is progressing without requiring every engineering team to maintain a duplicate representation of its activities.

This approach preserves local engineering autonomy while improving enterprise visibility.

7. Let Automation Handle Reporting. Let Humans Handle Decisions.

The next generation of engineering management should not require a collection of AI agents arbitrarily deciding whether projects are complete.

We already have mature technologies for deterministic enforcement.

Git events.

CI/CD pipelines.

Automated tests.

Security gates.

Policy checks.

Deployment verification.

These systems should establish facts.

AI can help interpret complicated results, identify missing evidence, summarize exceptions, and recommend corrective actions.

Humans remain accountable for business decisions, engineering tradeoffs, and acceptance.

The responsibility model becomes straightforward.

Human Engineering Lead

Owns outcomes, priorities, boundaries, dependencies, and acceptance.

AI-Enabled Engineering Team

Designs, implements, tests, integrates, and validates engineering changes using appropriate human and AI capabilities.

Shared Engineering Services

Provides reusable skills, deterministic hooks, governed tools, CI/CD controls, security policies, and engineering standards.

Outcome Board

Presents the current state of measurable outcomes using verified evidence.

No additional management layer should be introduced unless it demonstrably improves the process.

8. The Repogenic Connection: Engineering That Improves Itself

An automated Outcome Board becomes even more powerful when connected to a repeatable engineering learning process.

This is where the Repogenic Loop becomes relevant.

Every engineering effort generates more than software.

It generates knowledge.

What was requested?

What context was required?

What implementation was attempted?

What succeeded?

What failed?

What evidence supported the decision?

What reusable engineering capabilities should be improved?

These observations can inform future intents, engineering standards, automated validations, and reusable skills.

The objective is not simply to finish engineering work.

It is to improve the engineering system through the evidence produced while doing that work.

In this model, repositories don’t merely store code.

They preserve the engineering knowledge and evidence necessary to support future execution.

And the Outcome Board provides a management-level view of those results.

Engineering execution produces evidence. Evidence informs decisions. Decisions improve future execution.

That is how an engineering organization can become progressively more effective without creating additional reporting bureaucracy.

9. What Happens to Scrum and Agile?

I don’t believe organizations need another methodology war.

Scrum has contributed important practices to software development.

Agile emphasizes collaboration, responsiveness, working software, and continuous improvement.

Those principles remain valuable.

What deserves reconsideration is the assumption that software delivery must be managed through fixed-duration sprints, manually maintained stories, and prescribed reporting ceremonies.

AI changes the speed and structure of engineering execution.

Management practices should evolve accordingly.

Sprint planning can evolve into outcome and intent definition.

Backlog refinement can evolve into progressive intent refinement.

Daily status meetings can become exception-driven coordination.

Sprint reviews can evolve into evidence-based acceptance.

Retrospectives can become continuous engineering learning.

And traditional work boards can evolve into automatically generated Outcome Boards.

Organizations may still choose periodic planning cycles or coordination meetings.

The distinction is that these practices should exist because they solve real problems, not because a methodology requires them.

We should preserve the principles of Agile while allowing its operating model to evolve.

10. Is Anyone Already Building This?

The industry is clearly moving toward AI-assisted engineering coordination.

GitHub supports automated project workflows and cross-repository project management.

Linear has introduced AI-assisted project updates and event-driven agent workflows.

Atlassian is integrating AI agents into Jira.

Other platforms are connecting source control, automation, and project management more closely.

These developments are encouraging.

But they also raise a larger architectural question.

Should we keep improving the automation of traditional work items, or should we reconsider whether those work items need to remain the central management abstraction?

The proposal here takes the second approach.

Make measurable outcomes primary.

Make engineering intent explicit.

Let execution systems produce evidence.

Generate management visibility from that evidence.

Reserve human attention for decisions, exceptions, and acceptance.

The opportunity is not merely to automate the existing process.

It is to simplify the process itself.

11. A Practical Proof of Concept

I would like to see this concept tested in a real enterprise engineering environment.

Not through another extensive presentation or speculative framework.

Through a working proof of concept.

Start with one project containing three repositories.

Define several measurable outcomes.

Connect repository-level engineering intents to those outcomes.

Use existing CI/CD capabilities, source control events, automated validation, and deployment evidence to generate an Outcome Board.

Require no manual engineering status updates.

Then measure the results.

Can the board accurately reflect engineering progress?

Can managers understand cross-repository dependencies?

Can the system identify failures and missing evidence?

Can human acceptance remain explicit and auditable?

Does the approach reduce reporting overhead?

Does it improve visibility into actual outcomes?

And most importantly:

Can the organization manage engineering delivery more effectively with less administrative work?

If the evidence supports the approach, expand it.

If it doesn’t, refine the design.

Complexity must earn its existence.

12. The Future of Agile May Be Less About Managing Work and More About Verifying Outcomes

For years, software engineering management has concentrated on organizing, assigning, estimating, tracking, and reporting work.

These functions are not inherently unnecessary.

But the mechanisms used to perform them deserve reconsideration.

AI-native engineering creates an opportunity to connect business intent directly to engineering execution and measurable results.

Repositories can contribute evidence.

Automation can establish verified progress.

AI can assist with interpretation and coordination.

Humans can focus on outcomes, decisions, and acceptance.

And management can gain visibility without requiring engineers to spend additional time reporting information the engineering systems already possess.

The evolution I propose is straightforward:

From Scrum Boards to Outcome Boards.

From User Stories to Progressive Intent.

From Manual Reporting to Automated Evidence.

From Sprint Completion to Outcome Achievement.

From Managing Activities to Managing Results.

This is not a declaration that Agile has failed.

It is a proposal for its next evolution.

An evolution that recognizes how software engineering is changing and asks management practices to change with it.

The technology required to begin exploring this approach already exists.

What remains is to connect the pieces, test the operating model, and demonstrate whether it produces better results.

The next generation of engineering management should not ask engineers to explain what their systems already know.

It should use that knowledge to help organizations achieve what matters.

Mark Kendall

Intent-Driven Engineering | Repogenic

Proposed engineering operating model — open for discussion, experimentation, and enterprise proof of concept.

A note about the market research

I found four relevant platforms worth watching. They overlap with portions of the proposal, but none of the material I reviewed establishes the complete repository-generated, intent-driven, outcome-verified model described in the article.

Platform

What already exists

Where our proposal differs

GitHub Projects

Actions and APIs automate project items across repositories.

Outcomes and measured results become primary, rather than issues and pull requests.

Linear

AI-assisted project updates, automated workflows, and GitHub triggers.

Management state is generated from engineering evidence rather than maintained in a separate work system.

Atlassian Jira

AI agents can work on issues and participate in workflows.

The project board becomes a view of outcome evidence, not primarily a collection of issues.

Plane

GitHub synchronization, automatic status changes, and AI agents.

Outcome verification takes precedence over tracking issue completion.

Sources: