Scrum Is Dead. Your Backlog Is a Graveyard.

Hossein Najmi — Tue, 24 Feb 2026 16:58:55 +0000

Scrum Is Dead. Your Repo Replaced It.

I never believed in Scrum.

I want to be upfront about this because I think it matters for what follows. This isn't a post-hoc rationalization where I discovered AI coding tools and then decided Scrum was bad. I have felt, for years, that something was fundamentally wrong with the way our industry manages software development — and I just couldn't prove it.

I remember sitting in sprint planning sessions watching a room full of talented engineers spend two hours debating whether a task was a 5-point or an 8-point story. I remember thinking: we could have built the thing in the time we just spent talking about building the thing. I remember retrospectives where we wrote the same sticky notes every two weeks ("communication could be better", "too much context-switching") and nothing changed. I remember velocity charts that told managers a comforting fiction about predictability while developers quietly knew the numbers were gamed to look smooth.

But I kept my mouth shut, mostly. When you question Scrum in a software organization, people look at you like you just questioned gravity. Scrum has certifications. It has an industry of consultants. It has books and conferences and a manifesto that everyone treats like scripture. Questioning it marks you as someone who "doesn't get it" or "isn't a team player." So I smiled through the standups and planned the sprints and felt like an outcast who could see something nobody else wanted to see.

Then AI coding assistants arrived. And suddenly I had proof.

1. The Moment Everything Changed

The shift didn't happen in one dramatic moment. It crept up on me over 2024 and 2025 as the tools got better. First it was GitHub Copilot doing decent autocomplete. Then Cursor turned the entire IDE into a conversation. Then Claude Code emerged as what Karpathy correctly identified as "the first convincing demonstration of what an LLM Agent looks like — something that in a loopy way strings together tool use and reasoning for extended problem solving."

I build production SaaS products. Not toy projects — complex systems with domain-specific business logic, multi-tenant architecture, licensing systems, third-party integrations, the works.

At some point in mid-2025, I realized that my actual workflow had completely diverged from our "official" Scrum process. On paper, we had sprints and tickets and a backlog. In practice, I was doing something entirely different:

I'd open Claude Code or Cursor and describe the feature I wanted to build
Together with the AI, I'd write a detailed markdown spec — edge cases, data model, API contracts, UX flow
I'd save that as a .md file in the repo
Then I'd execute it — again with AI assistance
AI would write tests. AI would write docs. I'd update the plan file.
Ship.

The entire cycle — from idea to shipped, tested, documented feature — was happening so fast that the Scrum process around it became the bottleneck. By the time I would have created a Jira ticket, explained it in sprint planning, estimated it, assigned it, and waited for the sprint to start, the feature was already done. Not half-done. Done. Tested. Documented. Merged.

That's when I stopped pretending.

2. What My Actual Workflow Looks Like (With Real Tools)

I want to be concrete here because I've read too many thought pieces that stay at the abstract "AI will change everything" level. Here's specifically what I do and which tools I use.

Planning: Claude Code + Cursor

Every feature starts as a conversation. I open Claude Code in my terminal (or Cursor's Composer) and describe what I need. Not in ticket format — in the way you'd explain something to a very smart colleague. The AI asks clarifying questions, proposes data models, flags edge cases I missed, and suggests approaches.

The output is a markdown plan file. It looks something like this:

# Feature: Floating License Pool Management

## Context
The platform currently supports named-user licenses. We need to add
floating license support where a pool of N licenses is shared across
an organization, with concurrent usage limits enforced in real-time.

## Data Model
- LicensePool: { orgId, productId, totalSeats, activeCheckouts[] }
- LicenseCheckout: { userId, poolId, checkedOutAt, expiresAt, heartbeatAt }

## API Contract
- POST /api/license-pools/{id}/checkout → 200 | 409 (pool exhausted)
- POST /api/license-pools/{id}/checkin
- GET  /api/license-pools/{id}/status → { total, available, checkouts[] }

## Edge Cases
- User closes app without checking in → heartbeat timeout (5 min)
- Two users checkout simultaneously when 1 seat left → optimistic locking
- Org admin force-revokes a checkout mid-session

## Implementation Notes
- Use Redis for real-time seat counting (atomic INCR/DECR)
- Postgres as source of truth with eventual consistency
- WebSocket push to notify clients when seats become available

## Status: IN PROGRESS (started 2026-02-20)
## Tests: Unit + integration written, E2E pending

That single file is richer, more detailed, and more useful than any Jira ticket I've ever written. And it took 20 minutes to create collaboratively with AI, not 2 hours of sprint planning.

Execution: Claude Code + Cursor (with Copilot for speed)

For implementation, I use a combination:

Claude Code for complex, multi-file changes. It understands the whole repo and can make coordinated changes across services, models, controllers, and tests in one go. The terminal-native approach lets me work inside my existing environment with all my git config, env variables, and tooling. This is what Karpathy meant when he said Anthropic "got the order of precedence correct" — the AI runs where your code runs, with your context, not in a cloud sandbox.
Cursor for the IDE-level flow when I want to see changes visually, use its Composer for iterative refinement, and leverage its codebase indexing. The multi-model flexibility is huge — Claude for complex reasoning, faster models for quick edits.
GitHub Copilot still runs in the background for inline completions. It's excellent at the small stuff — finishing a function signature, writing a repetitive pattern, suggesting the obvious next line. Think of it as cruise control while Claude Code and Cursor are the autopilot.

A typical execution session looks like this in Claude Code:

$ claude

> Look at plans/features/floating-license.md and implement it.
  Start with the data model and migrations, then the API endpoints,
  then the Redis integration for real-time seat counting.
  Follow the patterns in our existing license code.
  Write tests for each layer as you go.

# [Claude Code reads the plan file, examines existing codebase patterns,
#  creates migration files, models, services, controllers, tests...
#  commits each logical chunk with meaningful messages]

Karpathy recently evolved his terminology from "vibe coding" to "agentic engineering" — because for professional use, it's not about vibes at all. It's about orchestrating AI agents with oversight and scrutiny to produce production-quality code. That's exactly what this is. I review every change. I guide the architecture. But the AI does the typing, the pattern-matching, the boilerplate, and increasingly, the edge-case thinking.

Testing: AI-Generated with Human Review

After implementation, I ask Claude Code to write comprehensive tests:

> Write tests for the floating license module. Include:
  - Unit tests for the LicensePool service methods
  - Integration tests for the API endpoints
  - Specific tests for the edge cases in the plan file
  - Test the Redis seat counting under concurrent access
  Run them and fix any failures.

The AI writes tests that cover the implementation it just built — plus the edge cases from the plan file. Important nuance: I also ask it to write adversarial tests. "Try to break the concurrent checkout logic. What happens if Redis goes down mid-checkout? What if the heartbeat job crashes?" This catches things that happy-path tests miss.

I won't pretend AI-generated tests are perfect. They tend to test what the AI built, which means they share the same mental model and can have blind spots. I do periodic manual exploratory testing and occasionally bring in real users for QA. But the baseline test coverage AI produces in minutes used to take days.

Documentation: A Byproduct, Not an Afterthought

This is the part that still amazes me. Documentation used to be the thing nobody wanted to do and everyone complained was outdated. Now it's generated automatically from the plan files and the code itself:

> Update the API documentation for the license management endpoints.
  Generate it from the actual route definitions and the plan file.
  Include request/response examples from the test fixtures.

The docs are always current because they're generated from the source of truth — the code and the plan files. They decay at the same rate as the code itself, which is to say: they don't decay, because when the code changes, the docs get regenerated.

3. The Repo Is the Project Management Tool

Here's the paradigm shift that I think most teams haven't internalized yet. Once you adopt this workflow, your Git repository is no longer just where code lives. It IS your project management system. Your knowledge base. Your documentation hub. Your decision log. Your onboarding guide. Everything.

Here's what my repo structure looks like:

my-product/
├── src/                          # the product
├── tests/                        # AI-generated + manual regression
├── docs/                         # AI-generated, always current
│   ├── api/                      # endpoint documentation
│   ├── architecture/             # system design docs
│   └── guides/                   # user-facing help content
├── plans/
│   ├── features/                 # MD spec per feature (past + present)
│   │   ├── floating-license.md
│   │   ├── invoice-pdf-gen.md
│   │   └── ...
│   ├── bugs/                     # reported → investigated → resolved
│   │   ├── BUG-session-timeout-race.md
│   │   └── ...
│   └── decisions/                # architectural decision records
│       ├── ADR-001-redis-for-licensing.md
│       ├── ADR-002-auth0-over-custom-auth.md
│       └── ...
├── ROADMAP.md                    # living priority list
├── CHANGELOG.md                  # what shipped and when
├── CLAUDE.md                     # AI agent instructions for this repo
└── README.md                     # onboarding for next human or AI

Every plan, every reported bug, every architectural decision, every feature spec — it all lives in the repo. It's versioned. It's searchable. It's diffable. It's branchable. And now — critically — it's queryable by AI agents in natural language.

The CLAUDE.md file (or AGENTS.md in some setups) is worth highlighting. It's a file that gives AI coding agents context about your project — coding conventions, architecture patterns, how to run tests, what to avoid. Every AI agent that touches your repo reads this first. It's the onboarding document for your AI team members.

Think about what this means for the classic "bus factor" problem. If I get hit by a bus tomorrow, the next person (or AI agent) who picks up this project can:

Clone the repo
Read README.md for orientation
Read ROADMAP.md to understand priorities
Browse plans/features/ to see what's been built and what's queued
Browse plans/decisions/ to understand why things were built a certain way
Browse plans/bugs/ to see known issues and their resolution history
Read CHANGELOG.md to understand what shipped recently
Start working

This is more context than any Jira board, Confluence wiki, or sprint retro has ever provided. And it's all in one place, version-controlled, and maintained as a natural byproduct of the development workflow — not as a separate documentation tax.

4. Why Tickets Were Always a Bad Abstraction

Now that I've described what replaced them, let me explain why I think tickets were always the wrong abstraction — even before AI.

A Jira ticket is fundamentally a communication artifact. It exists to transfer understanding from the person who knows what to build to the person who will build it. Every field is designed to solve a coordination problem:

Title/Description: so someone else can understand the work
Story Points: so managers can forecast timelines
Assignee: so we know who's doing it
Status columns: so we know where it is in the pipeline
Sprint: so we batch work into time-boxed cycles
Acceptance Criteria: so QA knows when it's done
Comments: so the team can discuss asynchronously

Every one of these fields is a lossy compression of the real plan. The description never captures every edge case. The story points are a rough guess dressed up as science. The status column has at best 5 states for what's actually a continuous process. The acceptance criteria are a shadow of the real test suite.

The plan file in the repo is the uncompressed version. It has everything — the context, the data model, the API contract, the edge cases, the decisions, the status, and it evolves with the work. The ticket was always a proxy. We just didn't have a better option.

Now we do. And the proxy can go away.

5. The Documentation Structure That Actually Works

I've iterated on the repo structure above through trial and error. Here are the patterns that work.

Feature Plan Files

These should follow a consistent template:

# Feature: [Name]

## Context
Why are we building this? What problem does it solve?

## Data Model
Tables, fields, relationships. Actual schema, not hand-wavy descriptions.

## API Contract (if applicable)
Endpoints, methods, request/response shapes.

## UI/UX (if applicable)
Key screens, user flows, interaction patterns.

## Edge Cases
The things that will bite you if you don't think about them now.

## Implementation Notes
Technical approach, libraries, patterns to follow.

## Dependencies
What needs to exist before this can be built?

## Status: [NOT STARTED | IN PROGRESS | COMPLETE | SHIPPED]
## Shipped: [date, or blank]
## Tests: [coverage status]

Bug Reports

These should include reproduction steps, root cause analysis, and the fix — not just "it's broken":

# BUG: Session timeout race condition

## Reported: 2026-02-15
## Severity: High
## Status: RESOLVED

## Symptoms
Users occasionally get logged out mid-action when their session
token refreshes at the same moment as an API call.

## Reproduction
1. Set token expiry to 30 seconds (for testing)
2. Start a long-running action (e.g., save a large record)
3. Wait until the token refresh fires mid-request
4. Observe 401 response on the original request

## Root Cause
The refresh token endpoint was not atomic — there was a window
where the old token was invalidated but the new one hadn't been
stored yet. Any request during that window would fail.

## Fix
Implemented token overlap window: old token remains valid for 30s
after new token is issued. See commit abc1234.

## Regression Test
tests/integration/auth/session-refresh-race.test.ts

That bug report is a permanent piece of institutional knowledge. Six months from now, when someone encounters a similar issue, they (or an AI agent) can search the repo and find not just that it happened, but why it happened and how it was fixed. Try doing that with a closed Jira ticket.

Architectural Decision Records (ADRs)

The most underrated practice in all of software engineering. They answer the question everyone asks but nobody documents: why did we build it this way?

# ADR-001: Redis for Real-Time License Seat Counting

## Date: 2026-02-18
## Status: Accepted

## Context
Floating licenses need real-time seat counting with sub-second
response times. Two users checking out the last seat simultaneously
must be handled atomically.

## Options Considered
1. Postgres with SELECT FOR UPDATE → too slow under contention
2. Redis INCR/DECR with Postgres as source of truth → fast + reliable
3. In-memory counter in the app server → doesn't work multi-instance

## Decision
Option 2. Redis for real-time counting, Postgres for durability.
Reconciliation job runs every 5 minutes to catch any drift.

## Consequences
- Adds Redis as an infrastructure dependency
- Need monitoring for Redis/Postgres drift
- Checkout latency drops from ~200ms to ~5ms

Without this, six months from now someone will look at the Redis dependency and ask "why don't we just use Postgres for this?" And nobody will remember the answer. With this, the answer is permanent, searchable, and versioned.

6. The Bold Predictions

I'll borrow from Karpathy's honesty here and say these are personally held beliefs, not certainties. But I believe them strongly enough to bet my own workflow on them.

Jira, Linear, and traditional PM tools will either pivot or become legacy. The entire value proposition of ticket-based project management — create, estimate, assign, track, review — assumes human throughput as the bottleneck. When AI is the executor and the repo is the tracker, the ticket abstraction has no audience.

The Scrum Master role will disappear from most small-to-mid-size teams within three years. Not because the people are bad — many are excellent facilitators. But because the coordination problems the role exists to solve are evaporating. The best Scrum Masters will evolve into what I'd call "AI workflow architects" — people who design and optimize the human-AI development loop.

Story points will be remembered the way we remember punch cards — a quaint artifact of a constraint that no longer exists. When AI can execute a feature in hours, historical velocity is meaningless for forecasting. Teams will shift to appetite-based planning: how much time is this worth, not how long will it take.

Solo developers and tiny teams will outship departments. This is already happening. The leverage that AI provides to one skilled person with clear product vision and domain expertise is staggering. A product leader who can work directly with AI coding agents will produce more than a 10-person team running Scrum with 30% of their time spent on ceremonies.

The repository will become the universal system of record. Code, plans, bugs, decisions, documentation, project status — all in one place, all versioned, all AI-queryable. The era of scattered tools (one for tickets, one for docs, one for code, one for chat, one for CI) is ending.

7. What Agile Got Right (And What Dies)

I want to be precise here because I'm not arguing against Agile's principles. The Agile Manifesto's four values are timeless:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

My AI-native workflow embodies these more purely than Scrum ever did. I'm shipping working software continuously. I'm responding to change in real time. I'm not hiding behind sprint boundaries or process overhead.

What's dying is not Agile the philosophy. What's dying is Scrum the framework — the ceremonies, the roles, the certifications, the two-week time boxes, and the entire industry of consultants, tools, and training that grew up around them.

The irony is poetic: the methodology that told us to value "individuals and interactions over processes and tools" became the most process-heavy, tool-dependent methodology in the history of software engineering.

8. The Wake-Up Call

If you're a developer, here's the thing I wish someone had told me earlier: you don't need permission to stop doing something that doesn't work. The feeling I had in those sprint planning meetings — that something was wrong, that this overhead wasn't necessary, that the ceremonies had become cargo cult — that feeling was correct. I just didn't have an alternative to point to.

Now I do. And so do you.

Start small. Pick your next feature. Instead of creating a Jira ticket, write a markdown plan file. Put it in your repo. Use Claude Code or Cursor to help you spec it out, build it, test it, and document it. See how it feels. See how fast you ship.

Then ask yourself honestly: did the sprint ceremony add anything that the plan file didn't?

Karpathy wrote that "vibe coding will terraform software and alter job descriptions." I think he's right, but I'd go further: it's not just coding that's being terraformed. It's the entire development process — planning, estimating, tracking, documenting, and communicating. All of it is being compressed into a tighter, faster loop where the repo is the single source of truth and AI is both the builder and the librarian.

The developers who figure this out first won't just be faster. They'll be operating in a fundamentally different paradigm. And catching up to a paradigm shift is much harder than catching up to a competitor.

The future of software development isn't a better framework. It's no framework at all — just a well-organized repo, a clear vision, and an AI that never gets tired.

TLDR. I never believed in Scrum, even before AI proved me right. My current workflow — AI-planned, AI-executed, AI-tested, AI-documented, all tracked in repo markdown files — ships faster than any sprint ever did. The repo is the project management tool. Tickets are dead. Ceremonies are dead. The Agile principles survive, but the Scrum framework doesn't. If you're still arguing about story points in a Monday morning meeting, you're playing a game that already ended.

Hossein Najmi — Head of Product at ScaffPlan

DEV Community: Hossein Najmi