Scrum is the most used and the most misunderstood framework in software development. The majority of teams who say they do Scrum are doing something else: a way of working with two-week blocks, daily status rounds and a task board — without the mechanisms the benefit comes from.
That is not a moral problem. It is a practical one: those teams carry the cost of the framework without receiving its return, and understandably conclude that Scrum does not work.
The core is not the sprint
What makes Scrum effective is not the sprint as a period of time but what is supposed to exist at the end of each one: a potentially shippable result. That requirement forces a series of things — that work is cut small enough, that quality is not deferred, that a result can be demonstrated.
Remove that requirement and what is left of the sprint is a calendar grid. A team that is "almost finished" at sprint end and carries on in the next sprint does not have a sprint but a subheading. That is where most Scrum adoptions fail — not on the ceremonies but on done being undefined.
The roles and who actually fills them
The product owner role is the most demanding and the most frequently under-filled. It requires three things at once: authority to decide on substance, availability to the team, and willingness to say no. Missing any one of them produces the most common case of all — a product owner who passes requests along instead of prioritising.
A passed-along request is not prioritisation. When everything enters the backlog and the order emerges from how loudly people ask, it is not the product deciding but the organisation. The team notices quickly and stops taking the order seriously.
What the retrospective would have to achieve
Of all the elements, the retrospective has the greatest leverage and the lowest quality of execution. Its purpose is not to name problems — almost everywhere manages that. Its purpose is to decide a change that becomes visible in the next sprint.
A retrospective without a decided change is a conversation. After three or four such rounds a team stops naming problems, because nothing changes anyway — and the framework’s most effective mechanism has been quietly abolished. The simplest countermeasure is a rule: exactly one change per retrospective, with an owner, reviewed at the start of the next.
Estimating is not an end in itself
Few topics consume more time than estimates. Yet the value of an estimate is not the number but the conversation it triggers: where two people estimate very differently, they have understood the work differently — and that difference is the valuable information.
Where estimates get reinterpreted as commitments to be measured against, the effect inverts. Teams then estimate defensively, the numbers grow larger and less informative, and the original purpose is lost. Using estimates as a performance measure produces better estimates and no better results.
When Scrum is the wrong choice
Scrum fits badly when the work consists mostly of unpredictable, short-notice demands. A team in an operations or support context cannot plan a sprint when half the content arrives during it. Trying anyway produces sprints that get overturned every time — and the experience that planning is pointless.
For that case a flow-based approach with a limit on parallel work is the better answer. That is not a step backwards but choosing the tool by the task. Equally, Scrum does not fit a project whose scope is entirely fixed and will not change — there the mechanism creates effort without return.
A usable test
Whether a team is really doing Scrum can be recognised from two questions. First: is there a binding definition of done that also holds under time pressure? Second: did the last retrospective lead to a visible change? Where both answers are yes, the framework generally works. Where one is no, no additional ceremony helps.