Scrum is dying, story points are stupid, and true agility lives on

People often say "agile is dead," but they usually mean to say scrum instead of agile. This article explains why agile isn't dead, just misunderstood.

Agile roots and the rise of scrum

In 2001 a group of software practitioners published the Agile Manifesto to challenge heavyweight, plan‑driven methods. Its values are as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

No single framework was prescribed. Instead the manifesto inspired (and was inspired by) many approaches. I’ve listed them in order of introduction below and found some historical gems for some of the links to learn more. So check those out, you won’t be disappointed.

• Late 1940s

  • Kanban introduced by Taiichi Ohno (Toyota). Helps visualize workflows, limits work in progress to cut bottlenecks and waste, and supports continuous delivery in manufacturing or software without fixed timelines

• 1950s - 1960s

  • Incremental and Iterative Development (IID) evolved in early software projects through the government and organizations like NASA. Breaks large work into small chunks for parallel development, early feedback, and risk reduction to avoid big failures at the end.

• 1980s

  • Spiral Model introduced by Barry Boehm in 1986, combines iteration with risk analysis and prototyping to handle uncertainty and evolving needs in complex software projects

• Early 1990s

  • Rapid Application Development (RAD) introduced by James Martin in 1991 after developing it at IBM in the 1980s, speeds up building prototypes and getting user feedback to create functional systems quickly, countering slow traditional methods.

  • Dynamic Systems Development Method (DSDM) introduced in 1994 by Jennifer Stapleton and DSDM Consortium building on the principles of RAD by adding more governance and structure to the process.

  • Scrum introduced by Jeff Sutherland and Ken Schwaber in 1995, manages complex products through short sprints, roles like product owner, and daily check-ins to adapt quickly and deliver value often.

• Late 1990s

  • Extreme Programming (XP), introduced in 1996 by Kent Beck. Intended to increase software quality and responsiveness with practices like pair programming and test-driven development for fast-changing requirements.

  • Feature-Driven Development (FDD) introduced in 1997 by Jeff De Luca to meet the specific needs of a 15-month, 50-person software development project at a large Singapore bank in 1997.

  • Crystal Clear, introduced by Alistair Cockburn in 1997, tailors processes to team size and project type, prioritizing people, communication, and reflection over rigid rules for better collaboration.

  • Adaptive Software Development (ASD), introduced by Jim Highsmith and Sam Bayer, deals with dynamic, non-linear projects by using speculate-collaborate-learn cycles to adapt and reduce waste in complex environments.

• Early 2000s

  • Agile Manifesto is introduced in 2001

  • Extreme Project Management (XPM), introduced in 2001, to tackles high-uncertainty projects with constant adaptation, trial-and-error, and short bursts for volatile environments

  • Lean Software Development is introduced in 2003 by Mary and Tom Poppendieck. Applies lean principles to eliminate waste, deliver fast, and optimize value in software, inspired by manufacturing efficiency.

  • Adaptive Project Framework (APF), introduced by Robert Wysocki, manages projects with unknown factors by focusing on available resources and iterative cycles for flexibility in IT.

  • Scrumban introduced by Corey Ladas in 2008 and merges scrum's structure with kanban's flow for teams transitioning or needing a hybrid to balance planning and continuous work.

• 2010s and later

  • Dual-Track Agile (DTA), introduced by Marty Cagan and Jeff Patton (unintentionally), splits discovery (user needs, validation) from delivery (building) to reduce wasted effort and ensure solutions fit problems.

  • Scaled Agile Framework (SAFe) introduced by Deal Leffingwell in 2011 to scale agile practices across large organizations, aligning multiple teams and incorporating lean for complex enterprise coordination. Check out this article on SAFe’s history since 2011.

  • Disciplined Agile (DA), introduced in 2012 by Scott Ambler and Mark Lines, offers a toolkit to mix agile and lean based on context, helping organizations choose workflows for diverse needs without strict rules.

  • Large Scale Scrum (LeSS), introduced in 2013 by Craig Larman and Bas Vodde, extends scrum to multiple teams while keeping it simple, avoiding extra layers to maintain agility at scale.

  • Nexus, introduced by Ken Schwaber in 2015, handles dependencies across scrum teams with an integration layer, for scaling without losing scrum's core benefits.

  • Scrum at Scale (S@S), introduced in 2018 by Jeff Sutherland. It addresses the challenges of scaling Scrum across multiple teams, departments, or entire enterprises while maintaining agility. Specifically, it enables linear scalability, coordinates ecosystems of teams efficiently, and minimizes bureaucracy to achieve business agility on complex, large-scale projects.

  • Hybrid Agile, introduced by many, combines agile flexibility with traditional structure for regulated industries or projects needing both iteration and upfront planning.

Scrum is only one of those many approaches to agile and it emerged in the early 2000s as a lightweight framework before the agile manifesto was created, that promised fast feedback and team autonomy. It defined roles, events, and artifacts to guide teams. Scrum’s clear structure and repeatable cadence made it easy to adopt and expand on as approaches like Nexus, LeSS, SAFe, S@S and Scrumban build on it’s foundation. Tool vendors like Atlassian built products that reinforced Scrum practices. Certifications and agile consultants popularized Scrum even more. Soon Scrum became synonymous with Agile in the marketplace.

When scrum events miss their mark

Simon Wardley said that all models are wrong but some are useful. The trick is to pick the right tool for the context. When teams treat frameworks like dogma, they lose sight of the mindset that made Agile successful in the first place.

Scrum events and artifacts were designed to empower teams and expose issues quickly. But when organizations misunderstand the purpose, those same rituals become burdens:

• Sprint Planning can turn into endless argument over story points instead of defining clear sprint goals.

• Daily Scrum sometimes becomes a status report rather than a quick sync on impediments.

• Backlog Refinement may feel like guesswork without clear criteria.

• Sprint Review often slides into a demo with no real feedback loop.

• Sprint Retrospective reduces to airing grievances when leadership ignores action items.

When meetings become chores, teams focus on outputs instead of outcomes. Velocity becomes the goal instead of the means. Leaders start to ask for more points per sprint rather than better value for customers.

AI is accelerating the need for change

Artificial intelligence tools like GitHub Copilot, AWS CodeWhisperer, and Cursor automate routine work. They suggest code, generate tests, flag potential bugs and even propose architecture patterns. At the same time, modern continuous delivery pipelines deploy changes with a single command. As a result:

• Two‑week sprints feel sluggish compared to daily or hourly releases.

• Manual estimations and planning poker sessions seem archaic and misaligned as leaders use these story point estimates as commitments.

• Async tools (Slack, Loom) let teams share updates without daily stand‑ups

That doesn’t mean all Scrum elements aren’t valuable. Backlog Refinement and Retrospectives remain vital for clarity and continuous improvement. But rigid timeboxes, fixed sprint lengths, and velocity tracking struggle to keep up with how fast teams can move today because of new tools.

Story points are stupid

Story points started in Extreme Programming as a quick way to size work based on relative effort. The idea was simple: compare two tasks and decide which is larger or smaller. No one expected story points to become an exact forecast.

Over time story points took on new roles:

• Commitment Contracts: “We will deliver 30 points this sprint.”

• Performance Scorecards: Teams and sometimes individuals judged by velocity.

• Estimation Gymnastics: Hours lost in planning poker instead of creating value.

In 2019, Ron Jeffries, one of the original XP practitioners, apologized for inventing story points. He noted that points were often misused to control teams rather than foster collaboration. When estimation becomes a performance metric, it undermines trust and agility.

Metrics that matter

Leading teams are moving away from story points and toward flow metrics that describe how work actually moves through the system.

• Cycle time measures how long a work item takes from start to finish.

• Throughput counts how many items ship in a given period.

• Work‑in‑progress limits prevent teams from starting too many tasks at once.

Strengthening Engineering Foundations

Before jumping to AI to do all the work, invest in core engineering practices that support agility:

• Shift quality left: Build quality into the development process, not at the end. Embrace practices like test-driven development (TDD), continuous integration, and developer-owned testing. The earlier bugs are caught, the cheaper and easier they are to fix.

• Clear definition of done: “Done” should mean more than “code is merged.” It means peer-reviewed, tested, documented, and deployable. A shared Definition of Done ensures clarity, accountability, and confidence across the team.

• Continuous delivery: Use modern CI/CD pipelines to build, test, and deploy automatically. Releasing value shouldn’t require a ceremony—it should be a click, or better yet, a commit.

• Make Work Visible: Track real flow metrics like cycle time and review turnaround. Visibility builds trust and helps spot bottlenecks before they become blockers.

When these foundations are strong, many of the rigid Scrum controls become redundant. You don’t need to estimate story points when you can measure actual flow. You don’t need to timebox planning when teams are already aligned through short feedback loops and clear quality gates. The focus shifts from process compliance to delivering working product with speed, clarity, and confidence.

Evolving in Small Steps

Your investment in Scrum is not wasted; it simply needs a new lens. By focusing on flow and fundamentals, teams regain independence and deliver more value.

1. Visualize your workflow in its current form.

2. Discuss your top blockers and root causes.

3. Experiment: run small tests (examples: micro‑batch planning, async stand‑ups, introduce flow metrics)

4. Refine based on outcome data, not fear or to chase maximum story points

5. Repeat continuously, leaning into lessons learned.

Rediscovering True Agility

Agile was never a set of ceremonies or an estimation game. It was a promise to value people, deliver working software, collaborate with customers, and adapt to change.

Scrum may be losing its shine, and story points may be more trouble than they are worth, but agility isn’t dead. It’s evolving. Frameworks can be, and should be, reimagined. Story points are stupid. But true agility lives on in flow, feedback, and continuous improvements by way of continuous learning.