Common Scrum Anti Patterns and What the Scrum Guide Says

Scenario questions on this assessment usually describe a team doing something the Scrum Guide never describes, and the tempting answer is the one that tidies the practice up. The answer the assessment rewards is the one that names what the framework actually says and lets the consequence follow. An anti pattern is a practice that looks reasonable, spreads easily and quietly removes something the framework depended on, so each of the six below is paired with the sentence that settles it.

The Daily Scrum held as a status report to the Scrum Master

The Daily Scrum is a fifteen minute event for the Developers, and its purpose is inspecting progress toward the Sprint Goal and adapting the plan for the next day of work. A round of updates delivered to the Scrum Master satisfies neither half, because the information travels out of the team and no plan changes as a result.

The tell is the direction people face. On a payments team where three Developers speak in turn to whoever is taking notes, nobody has replanned anything, and the event has become the status meeting that a working Daily Scrum removes the need for.

A Sprint running without a Sprint Goal

The Sprint Goal is the single objective for the Sprint, and the Guide requires it to be settled before Sprint Planning ends. A Sprint that opens with a list of items and no objective has lost what lets the Developers make tradeoffs while the Sprint is running, since any decision about what to drop needs something to protect.

Teams arrive here honestly. A Sprint Backlog assembled from six unrelated tickets on an internal admin tool offers no objective to write, which is information about how the Product Backlog has been ordered.

The Scrum Master assigning work to the Developers

The Developers decide who does what. They are the people the framework empowers to manage their own work, so a Scrum Master handing out tasks takes that decision back and the team learns to wait for the next allocation.

This practice survives because it works in the short run. Giving the migration off a legacy service to the one engineer who already knows it finishes more this Sprint and leaves a single point of knowledge for the next six.

The Sprint Review treated as a sign off gate

The Sprint Review is a working session. The Guide tells the Scrum Team to avoid limiting it to a presentation, so treating it as the meeting at which a stakeholder approves the Increment makes the event an inspection of the team and moves a decision the Product Owner holds.

The Guide settles it in one line, denying the Sprint Review any standing as a gate to releasing value. A search service team that holds a release until a steering group approves it at the Review is describing an organisational impediment, which the event itself cannot repair.

A Product Owner acting as a proxy with no authority

The Product Owner is one person, not a committee, and for Product Owners to succeed the entire organisation has to respect their decisions. A proxy fails both tests. Somebody gathering requirements from a steering group and carrying them to the team holds the title and none of the decision, so ordering the Product Backlog becomes transcription.

The symptom is a Product Backlog whose order changes after every stakeholder meeting. A scenario built on it is usually asking what gives the accountability its authority back, which is work on the organisation around the team.

Partial work carried into the next Sprint as though it were finished

An item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review, and it returns to the Product Backlog. Carrying it forward as nearly finished work damages the only measure a forecast rests on, because a count of items that met the standard stops meaning anything once some of them did not.

A billing job that is coded, untested and recorded as finished has moved the remaining effort somewhere nobody is counting it. The repair is ordinary. The item returns to the Product Backlog and competes for order with everything else there.

What the six anti patterns have in common

Every one of the six takes a decision away from the accountability that owns it and hands it to somebody else. That is the pattern worth carrying into the exam, because a scenario rarely names an anti pattern and almost always describes its symptom. Working back from the symptom to the displaced decision reaches the Guide's answer faster than recalling which practice has a name.

Common misconceptions

“An anti pattern is a practice the Scrum Guide forbids.”

The Guide describes a framework and carries very few prohibitions. Most anti patterns are practices it simply does not describe, and what makes each one a fault is the decision it moves away from the accountability the framework gave it.

Where this is examined
PSM I
Related material
Book
Essential Scrum, On the coaching stance and the anti patterns teams fall into.
Book
Scrum: A Pocket Guide, On what the framework prescribes and what it deliberately leaves open.
Book
Scrum Mastery: From Good To Great Servant-Leadership, On the moves a Scrum Master makes once a team has drifted.
Concepts