Your Scrum Isn't Scrum. The Scrum Guide Is 13 Pages. Your Process Has 300.

Source: Dev.to

Background

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.

The Scrum Guide (2020)

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.

Ten Common Folk Overlays

1. 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 handle 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 its 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.

2. 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

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.

3. 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.

4. A proper sprint is 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.

5. 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.

6. “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

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.

7. 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.

8. Sprint Retrospective must be a one‑hour, three‑column ritual

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.

9. Backlog refinement is a scheduled two‑hour Friday meeting

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.

10. Daily Scrum is a status‑update round‑robin

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 developers 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; another 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, especially 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 stand‑up. 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