Scrum is one of the most widely adopted frameworks in software development. It is also one of the most widely misunderstood. After twenty-five years of agile practice, the same myths keep reappearing; in retrospectives, in job postings, in boardroom presentations, and in the quiet frustration of engineers wondering why their “Scrum” feels like something else entirely.
The problem is not that teams fail at Scrum. The problem is that they implement a myth, then blame the framework.
Naming the myths is the first step toward doing Scrum well; or at least toward making a conscious, informed decision to do something better.
Myth 1: Scrum is a methodology
Scrum is a framework. The distinction matters enormously. A methodology tells you what to do and how to do it in detail. A framework gives you a lightweight structure and expects you to fill in the rest with your own judgment, your own practices, and your own context.
The Scrum Guide — the definitive source — is famously short. It was shortened deliberately in its 2020 revision, not because the authors ran out of ideas, but because the original was being treated as a rulebook rather than a starting point. Scrum intentionally leaves room. Treating it as a rigid methodology is what turns a sensible framework into a bureaucratic burden.
Myth 2: The Daily Scrum is a status meeting
This is perhaps the most costly myth in daily practice. The Daily Scrum, often called the daily standup, is not an opportunity for each team member to report progress to the Scrum Master or Product Owner. It is a planning event for the Development Team.
The Daily Scrum exists so the team can inspect their progress toward the Sprint Goal and adapt their plan for the next 24 hours. It is self-organization in action, not a status report.
When a manager enters the room and the team starts addressing them instead of each other, the event has already failed its purpose. The Scrum Master’s job in that moment is not to facilitate the meeting; it is to protect it and the team.
Myth 3: The Scrum Master is a project manager
The Scrum Master role has no authority over the team. None. They do not assign tasks, they do not track individual performance, and they do not own the delivery plan. What they do own is the process itself: ensuring Scrum is understood, enacted, and continuously improved. As such, they may also mentor stakeholders outside of the team, to ensure a common understanding and expectations on the team.
The confusion arises because many organizations retrofit the title onto an existing project manager role without changing anything else. The result is a Scrum Master who manages upward, shields the team from nothing, and wonders why velocity is flat. A Scrum Master is a servant-leader. The job is to remove impediments, coach the team toward self-management, and advocate for a way of working that actually produces results.
Myth 4: Scrum requires two-week sprints
The Scrum Guide specifies that a Sprint should be “one month or less“. Two weeks became the industry default not because it is universally optimal, but because it struck a reasonable balance for many teams in many contexts at a particular point in time. It became cargo-culted into a rule.
Some teams work better in one-week sprints. Others – particularly those doing complex research, hardware integration, or deeply regulated work – benefit from three or four weeks. The right sprint length is the one that allows the team to deliver something of value, inspect what happened, and adapt before the next cycle. That calibration is yours to make, not Scrum’s to dictate.
Myth 5: The Product Backlog must contain user stories
User stories (“As a [user], I want [something], so that [reason]”) are a technique popularized by Extreme Programming. They are not part of Scrum. The Scrum Guide does not mention user stories once.
Neither are Gherkin “Given [initial state], when [an event happens] then [the observable behavior shall happen]” statements. They are all tools.
A Product Backlog Item can be a user story, a bug, a technical task, a compliance requirement, a spike, or plain English prose. What matters is that each item is ordered, estimated to a useful degree, and understood well enough by the team to be actionable. The format is irrelevant. Insisting on user stories for every single backlog item, including infrastructure work and defect fixes, adds ceremony without value and forces artificial constructs onto work that does not fit the shape.
Myth 6: Scrum and Kanban cannot be combined
This myth usually comes from people who read one framework’s documentation and stopped there. Scrum and Kanban address different problems and operate at different levels of abstraction. Scrum provides a cadence, the Sprint, and a set of accountabilities and events. Kanban provides flow management and work-in-progress limits.
They are not competing religions. Many high-performing teams run Sprints as their planning and delivery cadence while using a Kanban board to visualize and limit work-in-progress within the Sprint. This hybrid is sometimes called Scrumban, though the label matters less than the outcome. The goal is always flow, quality, and learning — not doctrinal purity.
Myth 7: Velocity is a productivity metric
Velocity which is the sum of story points completed in a Sprint, is a forecasting tool. It exists to help teams predict how much work they can take on in the next Sprint, and to give stakeholders a rough sense of throughput over time. That is its entire purpose.
Velocity was never designed to compare teams, measure individual performance, or serve as a target to be optimized.
When management sets velocity targets, teams respond rationally: they inflate estimates. Points grow. Velocity grows. Nothing else does. The metric ceases to mean anything. Velocity should be a private planning tool for the team, not a KPI on a dashboard.
Myth 8: Scrum means no documentation
The Agile Manifesto – which is not Scrum, though Scrum is agile – values “working software over comprehensive documentation.” This is frequently misquoted as “working software instead of documentation.” It is not.
The manifesto explicitly acknowledges that both sides of the comparison have value. It simply asserts that one matters more. Scrum itself requires a Product Backlog, a Sprint Backlog, and an Increment, all of which are artifacts, which is to say, forms of documentation. In regulated industries, medical devices, aviation software, and financial systems, documentation is not optional. Scrum does not ask you to abandon it. It asks you to make it lean, timely, and purposeful rather than exhaustive and upfront.
Myth 9: The Sprint Review is a demo
A Sprint Review is a collaborative working session between the Scrum Team and key stakeholders. Its purpose is to inspect the Increment and adapt the Product Backlog based on what was learned. A demo is at most a part of that event, and often not even the most valuable part, since it is only a one-way presentation.
The most valuable part is the conversation that follows: What did the market do while we were building? What have we learned about what users actually need? What should we build next, and what should we stop building? When the Sprint Review becomes a performance in the form of polished slides, no surprises, and stakeholders nodding, it has stopped being an inspect-and-adapt event and started being a reporting ceremony. That is expensive time spent on the wrong thing.
Myth 10: Scrum scales naturally
Scrum was designed for a single team of roughly three to nine people. It was not designed for fifty teams, three time zones spanning half the globe, and a portfolio of interdependent products. The frameworks that attempt to scale Scrum — SAFe, LeSS, Scrum@Scale, and others — do so with varying degrees of overhead, prescription, and success.
None of them solve the fundamental coordination problem that emerges when the organization is larger than what a single Sprint can contain. Dependencies between teams, shared architectural components, regulatory approval chains, and competing backlogs require tools that go beyond what the Scrum Guide describes. Pretending otherwise — scaling Scrum by simply running more Scrums — produces coordination chaos that is neither agile nor efficient.
Scaling agile development
This is one of the core problems that Modelithe was designed to address: how to grow from a single agile team to a multi-team, multi-country organization without abandoning the principles that made the small team effective in the first place, while at the same time acknowledge that there are parts in predictive product management and enterprise budgeting that needs to be done on a timescale well exceeding that of a SAFe Planning Interval, and certainly a single Scrum sprint.
Scrum is a genuinely powerful framework when practiced as intended. The myths above are not abstract theoretical concerns. Every one of them produces real, measurable damage in real teams every day. Inflated velocity tells leadership a lie. Status-meeting standups waste thirty minutes and demoralize engineers. A Scrum Master who manages instead of coaches stifles the self-organization the framework depends on.
The good news is that each myth has a clear antidote: read the Scrum Guide, understand the intent behind each event and artifact, and resist the organizational gravity that pulls every new idea back toward the familiar shape of the old one.
Take a moment to think about your own team. Which of these myths are quietly running in the background of your current process? And what would change if you named them out loud in your next retrospective?