Originally published at theendofcoding.com.

The Scrum Guide is 13 pages. The terms "user story" and "epic" never appear in it. The word "velocity" appears zero times. Story points have not been mentioned since 2010. Planning poker, Fibonacci, "As a user, I want," Given/When/Then, two-week sprints — none of it is in there. What most engineering organizations call Scrum is a folk overlay assembled on top of the Guide over twenty years by books, tools, and consultants. Most of what your team fights about at sprint planning was never Scrum.

This is not a critique of Scrum. The Scrum Guide is fine. The bloat this article catalogs was added to Scrum — by mid- and large-sized enterprises that grafted on practices from books, tools, and consultants left and right until what took ten minutes to read became a process that takes three hundred pages to document. Most of it was added with good intentions. None of it was ever required.

That bloat is what compounds under AI acceleration. When execution was the bottleneck, an extra ceremony and a Fibonacci debate cost a sprint. When AI collapses the cost of writing code by an order of magnitude, the same ceremony and the same debate cost the entire week of work that used to live inside them. Process overhead that was tolerable at human-keyboard speed is now the bottleneck. The teams shipping at the speed AI actually enables are the teams that have stripped enterprise Scrum back to something close to the original 13-page document — and replaced the rest with workflows designed for the speed they work at, not the speed of fifteen years ago.

What the Scrum Guide actually contains

The Scrum Guide — written by Ken Schwaber and Jeff Sutherland, last rewritten in November 2020 — prescribes remarkably little:

• Three roles (Product Owner, Scrum Master, Developers).
• Five events (the Sprint itself, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective).
• Three artifacts (Product Backlog, Sprint Backlog, Increment).
• A Definition of Done.
• Sprints of "one month or less."

Each rewrite has removed prescription, not added it. Everything below is folk overlay — here are the ten biggest, with what to do about each.

The 10 myths at a glance

1. Scrum requires user stories (and epics)
2. Story points are a Scrum concept
3. Planning poker is a Scrum ceremony
4. Sprints must be two weeks
5. Velocity is a Scrum metric
6. "As a user, I want…" is mandatory
7. Fibonacci scales are more accurate
8. The Sprint Retrospective must be ritualized and recurring
9. Backlog refinement is a required ceremony
10. The Daily Scrum is a status-update meeting

Myth 01 — Scrum requires user stories (and epics)

The claim. Scrum teams track work as user stories. Larger groupings are epics. That's the structure.

The Scrum Guide. Refers to "Product Backlog Items." The terms user story and epic never appear in any version of the Guide.

The origin. Both come from Extreme Programming. Kent Beck's Extreme Programming Explained (1999) used "story" for a unit of user-facing work, with "epic" as the colloquial term for a story too large to deliver in one cycle. Mike Cohn formalized both in User Stories Applied (2004) and Agile Estimating and Planning (2005). Atlassian's Jira then institutionalized the Epic → Story → Sub-task hierarchy as a product feature, and a generation of tools followed Jira's lead. None of which makes any of it Scrum.

Do this instead. The term doesn't matter — different systems use different ones (issue, ticket, work item, task) and they all work fine. What matters is the underlying concept: a unit of work, ordered in a backlog. Hierarchy is useful — group related work together so progress on a larger initiative is visible — but two levels handles most needs: a grouping concept on top, a unit of work below. Two types — feature-shaped work and pure-technical work — is usually enough. Resist the temptation to configure ten work-item types each with their own custom workflow. Simpler tools are faster, the team's mental model stays lighter, and the simplification compounds with AI: agents reasoning about your backlog work better when there are fewer types and shapes to disambiguate.

Myth 02 — Story points are a Scrum concept

The claim. Every "real" Scrum team estimates in story points.

The Scrum Guide. Mandates estimation, prescribes no method. The Guide has not mentioned story points since 2010.

The origin. Ron Jeffries coined story points as part of Extreme Programming in the late 1990s — initially to abstract "ideal days" into a unitless number that prevented managers from locking in rigid commitments. Mike Cohn popularized them in Agile Estimating and Planning (2005). In a 2019 blog post titled "Story Points Revisited," Jeffries himself wrote:

"I like to say that I may have invented story points, and if I did, I'm sorry now."

— Ron Jeffries, 2019 (source)

He went on to call comparing teams on velocity "harmful." The person credited with inventing the unit publicly disowned it.

Do this instead. Estimate in real time units. Effort in hours. Duration derived from real team capacity, accounting for vacations, support load, and the percentage of development time that actually exists in a working week. The unit business leadership needs to plan around is a delivery date — and story points were a translation layer between something developers could approximate and something the business could schedule. Every link in that translation introduces distortion. Skip the layer.

Myth 03 — Planning poker is a Scrum ceremony

The claim. Real Scrum teams play planning poker to estimate together.

The Scrum Guide. Never mentions it. In any version.

The origin. James Grenning introduced planning poker in a 2002 paper titled "Planning Poker or How to avoid analysis paralysis while release planning" — written for Extreme Programming release planning, not Scrum. Mike Cohn later popularized it for Scrum teams in Agile Estimating and Planning (2005), which is also how it spread.

Do this instead. Asynchronous breakdown, AI-first estimation. Modern AI tools can read a change description, propose a breakdown, and estimate both the AI execution portion and the human review-and-validation portion as separate components of each work unit. Developers review those numbers the same way they review AI-generated code — not from scratch, but with judgment applied to a draft. Combining the AI portion and the human portion in each unit of work is often more accurate than a developer guessing in isolation, because both pieces become quantifiable once the scope is explicit. Dev leads clarify requirements where the AI was uncertain. The kickoff that replaces sprint planning is for alignment, not estimation: is the scope coherent, are the dependencies visible, is the duration realistic, are the risks understood. Planning poker made sense when estimation was hard and group calibration required a synchronous ritual. With AI carrying the first-pass numbers, the calibration ceremony has shrunk to a confirmation conversation.

Myth 04 — Sprints must be two weeks

The claim. A proper sprint is two weeks. One week is too short, three weeks is too long.

The Scrum Guide. "One month or less." That is the entire prescription. No specific duration.

The origin. The two-week default crystallized in the early 2000s as a compromise between "weekly is too much overhead" and "monthly is too long for feedback." Then Jira shipped two-week sprints as a default template in the mid-2000s, and a generation of teams inherited the cadence without questioning it.

Do this instead. Variable durations derived from effort and capacity. Each initiative gets its own duration window — calculated from estimated effort divided by available developer capacity, with a multiplier for meetings, reviews, and overhead. A small initiative might run a week. A platform migration might run six weeks. Forcing both into the same fixed two-week container is what makes sprints feel arbitrary — because they are.

Myth 05 — Velocity is a Scrum metric

The claim. You measure team performance with velocity. A healthy team has stable velocity.

The Scrum Guide. The word "velocity" appears zero times in any version of the Scrum Guide. It has never been a Scrum concept.

The origin. Velocity comes from Mike Cohn's books and the broader Agile-coaching ecosystem of the early 2000s. It became universal because dashboards needed something to chart and story-point throughput was easy to count.

Do this instead. Effort-based burndown tracked against a real time budget. Estimate effort in time units, log time as work progresses, watch the burndown deviate. Spike upward in remaining work? Scope was added — make the trade-off visible. No movement? Something is blocked — surface it. Steady drift? Underestimate — recalibrate. Burndown is variance detection, not performance scoring. It tells you when to have a conversation about reality, not when to congratulate or punish.

Myth 06 — "As a user, I want…" is mandatory

The claim. Every story must follow the "As a [role], I want [feature], so that [benefit]" template. It is what makes a story a "user story."

The Scrum Guide. Never mentions user stories or the template. The Guide refers to Product Backlog Items — no format prescribed.

The origin. The template was invented at Connextra Ltd., a London software company, in 2001 — originally called "role-feature-reason." Mike Cohn popularized it in User Stories Applied (2004). The Agile Alliance's own glossary, maintained by the organization that stewards the Agile Manifesto, describes the template this way:

"Training wheels… often outgrown once past the novice stage. Many novice teams fall into rote application… spending much effort and time on complying with user story templates is without much point."

— Agile Alliance glossary (source)

The Agile Alliance is, in effect, telling you to stop using their own template once you know what you are doing.

Do this instead. Direct, scannable titles that read as actions. Add auth retry logic. Implement search filtering. Refactor API query boundaries. The discipline the template was trying to instill — name the user, the capability, the reason — is still product thinking. You do not need a template to have that conversation. You need a team that asks those questions, and increasingly, AI assistance that translates intent into whatever structured artifact a downstream system actually needs.

Myth 07 — Fibonacci scales are more accurate

The claim. Estimating in 1, 2, 3, 5, 8, 13 is more accurate than linear scales because it acknowledges uncertainty grows with size.

The Scrum Guide. Does not mention Fibonacci.

The origin. Mike Cohn's Agile Estimating and Planning (2005). The argument was theoretically defensible — you cannot meaningfully distinguish between an 8 and a 9, so the gaps in the scale should grow. In practice, the gaps just give teams more numbers to argue about.

Do this instead. You don't need a scale at all, and most teams shouldn't have one. Estimate in real time — hours, days, whatever unit fits the work. Aim for the midpoint between your most optimistic case and your worst case: not so aggressive you fail most of your estimates, not so padded that you become the team consistently under-delivering against your own capacity. Precision improves as ideation gets closer to execution — rough estimates for early-stage ideas, refined as the work enters the planning window. Fewer layers between estimate and reality means more clarity for everyone — leadership, developers, the people doing the planning. If your tooling forces a numeric scale on you (some systems do), keep the mapping as simple as the team can guess on sight: every number is days is the safest bet. The anti-pattern is abstract, team-specific points that mean different things to different people across the org.

Myth 08 — The Sprint Retrospective must be ritualized and recurring

The claim. Every sprint ends with a one-hour retro. Three columns: what went well, what didn't, what to try next.

The Scrum Guide. The Sprint Retrospective exists as one of the five events. Its format is unspecified. Its frequency follows the sprint cadence — but the sprint cadence itself is up to the team.

The origin. The format with three columns and the standard prompts comes from agile-coaching practice, not the Guide. It is reasonable as a starting structure. It became a problem when teams kept doing it on autopilot for years, with the same stale findings, in meetings everyone attended out of obligation.

Do this instead. Inspect-and-adapt is the principle. The recurring meeting is not the principle. If the retro produces meaningful change, keep doing it. If it produces stale lists nobody acts on, change the format, change the cadence, replace it with a written reflection, or run it only when the team has something real to discuss. Rituals that no one believes in corrode trust. The Guide gives you permission to vary the format — most teams have just never used that permission.

Myth 09 — Backlog refinement is a required ceremony

The claim. Friday afternoons are for backlog refinement. The whole team. Two hours. Walk through the upcoming stories.

The Scrum Guide. Refinement is described as an ongoing activity — refining backlog items as needed throughout the sprint. No ceremony, no scheduled meeting, no required cadence is prescribed.

The origin. The recurring two-hour refinement meeting is enterprise-Scrum optimization for a world where everything had to happen synchronously and breaking down work required collective interpretation.

Do this instead. Just-in-time breakdown. The Dev Lead refines stories shortly before they enter execution. AI assists with decomposition, surfaces ambiguities, and drafts acceptance criteria. Targeted conversations replace whole-team meetings. Heavy upfront refinement on stories that may shift in priority is wasted effort. The simplest test: ask whether your refinement meeting changed anything you would not have figured out anyway. If not, it is overhead.

Myth 10 — The Daily Scrum is a status-update meeting

The claim. Stand up. Three questions. What I did yesterday, what I'll do today, what's blocking me. Round-robin around the team. Fifteen minutes.

The Scrum Guide. Specifies a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. The format is not prescribed. The audience is the developers, not stakeholders. The three-questions format is not in the Guide.

The origin. The three-questions format comes from XP-era practice and Mike Cohn-era coaching. It made sense in 2003 when the developers genuinely needed to coordinate verbally because tooling was thin. Today most of "what I did yesterday" is visible in pull requests, ticket history, and Slack threads. Speaking it aloud has become reporting, not coordinating.

Do this instead. The actual value of the Daily Scrum isn't the mechanical update — it's the unscheduled cross-pollination that happens when developers with different context are in the same room once a day. Someone mentions an escalation; someone else says wait, that sounds related to what I'm seeing in module X; a side-bar gets scheduled for later. New issues that nobody knew were issues get surfaced because somebody's experience caught a thread in somebody else's update. That's the meeting paying for itself, and it's especially valuable for unexpected work — escalations, support load, cross-cutting concerns — where the right person to talk to isn't obvious until somebody describes the problem out loud.

So keep the standup. Keep it fast. Lightweight visibility on what people are working on is real value as ambient awareness, not as a status report. Encourage tangents to become side-bars when they get long. And value the unexpected discussions over the predictable ones — that's where the meeting earns its keep.

The agreement this approach requires

Real-time-unit estimation, variable timeboxes, and burndown-as-variance-detection all rest on one cultural condition: estimates are honest probabilistic statements, variance gets surfaced early, and in return, leadership treats that variance as a planning input rather than a performance event.

Without that agreement, the failure mode is real and well-documented. Leadership treats every estimate as a contract. Developers learn to pad heavily or refuse to estimate at all. The estimate becomes either useless — too padded to plan around — or punitive, held against the team when reality diverges. At that point the rational defensive move is to retreat to story points, abstract velocity, and "we deliver value every sprint, ask no further questions" — abstraction layers that make the date conversation structurally impossible to have. That retreat is what a lot of enterprise Scrum is actually optimizing for. It is not a principled position. It is scar tissue from leadership cultures that punished honesty.

The alternative described above requires both sides to behave differently. Developers commit to estimating in real units, naming what the estimate assumes, and surfacing scope changes or unexpected complexity the day they discover them — not at sprint review. Leadership commits to treating those updates as the same kind of input as a market-data revision: re-plan around it, re-prioritize, decide what to cut. Not as a failure to manage.

If an organization can hold that agreement, it gets something the ceremony-heavy alternative cannot offer: a date to plan around, and a team trusted to tell you when the date moves and why. If it cannot — yet — that is a culture problem to address before it is a process problem to redesign. Naming the precondition honestly is the first step.

The Scrum Guide is fine. Enterprise Scrum is what's broken.

When this argument goes wrong, it goes wrong in one direction: people read it and conclude that Scrum is broken. That is the wrong conclusion.

The Scrum Guide is defensible. Its empirical philosophy — transparency, inspection, adaptation — is sound and stays sound. It is minimal by design. It accommodates the Timebox Method, Kanban, hybrid models, the workflow your team is about to invent. It has been getting less prescriptive with every revision, not more. The people who wrote it have spent twenty years quietly removing rules.

What broke under AI acceleration is not Scrum. It is enterprise Scrum — the folk overlay that most teams actually practice. The story-point estimation theater. The two-week cadence imposed by default. The velocity charts. The planning poker sessions. The "As a user…" ticket templates. The recurring refinement meetings nobody acts on. The retros that produce sticky notes nobody reads. The Jira workflows so complex they need a flowchart on the wiki.

That is the layer that gets in the way. That is the layer your team argues about. And almost none of it was ever Scrum.

A useful test, before defending any practice as "what Scrum requires": find it in the Guide. The Guide is 13 pages. It will take you ten minutes. If the practice is not there, it is a folk convention you have been told is mandatory. You can keep it if it is genuinely earning its keep — or you can replace it with something that fits how your team actually works.

Most teams already know enterprise Scrum is not serving them. The hard part has never been the diagnosis. The hard part is giving yourself permission to change it — and that starts with knowing which rules were never rules.