Posts

15 scrum anti-patterns killing your team's productivity

Illustrated team going through mechanical motions at a standup meeting with lifeless expressions, a stagnant agile board in the background

Matt Lewandowski

Last updated 16/02/202615 min read

Your team follows the Scrum Guide. You have a Product Owner, a Scrum Master, and a cross-functional development team. You run every ceremony on schedule. And yet nothing feels like it's working. The problem usually isn't that you're skipping Scrum events. It's that you're doing them in ways that look productive but actually erode the team's ability to deliver. These are anti-patterns: practices that feel normal, maybe even correct, but quietly destroy the feedback loops Scrum depends on. Here are 15 of the most common ones, organized by ceremony area. If you recognize more than a few, your process needs surgery, not a band-aid.

Sprint planning anti-patterns

Sprint planning sets the direction for the entire sprint. When it goes wrong, everything downstream suffers. For a full guide on doing this well, see how to run effective sprint planning meetings.

1. No sprint goal

What it looks like: The team pulls items off the top of the backlog until capacity runs out. There's no coherent theme or objective, just a pile of tickets. Why it's harmful: Without a sprint goal, the team has no shared purpose. When scope needs to be negotiated mid-sprint (and it always does), there's no framework for deciding what to cut. Every ticket feels equally important, so nothing gets cut, and the sprint overflows. How to fix it: Start every sprint planning session by articulating the sprint goal before selecting any backlog items. The goal answers "why does this sprint matter?" If the Product Owner can't articulate one, the backlog probably needs restructuring. For a step-by-step approach, the scrum ceremonies guide covers the full planning flow.

2. The Product Owner dictates scope

What it looks like: The PO walks into planning with a pre-selected list of items and tells the team what they will complete this sprint. Developers nod along. Why it's harmful: Sprint planning is a negotiation, not an assignment. When the PO dictates scope, developers lose ownership of their commitments. They stop pushing back on unrealistic timelines because they've learned it doesn't matter. The result: chronic overcommitment and silent burnout. How to fix it: The PO proposes priorities and explains the business context. Developers select what they can realistically commit to based on their capacity and the Definition of Done. The Scrum Master facilitates this as a two-way conversation, not a handoff.

3. Estimating during planning instead of refinement

What it looks like: The team encounters unestimated backlog items during sprint planning and spends 30+ minutes debating story points for each one. Why it's harmful: Planning is for selecting and committing to work, not for sizing it. When estimation bleeds into planning, the meeting runs long, energy drops, and the team rushes through the actual planning part. Worse, the PO can't properly prioritize items whose cost is unknown. How to fix it: Estimate during backlog refinement sessions held throughout the sprint. Use planning poker to keep estimation structured and time-boxed. By the time items reach sprint planning, they should already have estimates and clear acceptance criteria. If your estimates suffer from groupthink or anchoring bias, anonymous planning poker can help.

4. Chronic overcommitment

What it looks like: The team commits to more work than they can finish, sprint after sprint. Unfinished items roll over. Velocity numbers look good on paper because estimates are inflated. Why it's harmful: Overcommitment trains the team to treat sprint commitments as aspirational rather than real. It also erodes stakeholder trust. When everything is "almost done," nobody can predict when anything will actually ship.

Use yesterday's weather

The simplest capacity check: look at how much the team completed in the last three sprints, take the average, and plan for that. Don't plan for your best sprint. Plan for your average one.

How to fix it: Track actual velocity (completed, not committed) and use it as the upper bound for the next sprint. Leave buffer for unplanned work. If the team consistently finishes early, they can always pull more items from the backlog.

Daily standup anti-patterns

The daily standup exists to help developers coordinate. When it drifts from that purpose, it becomes the meeting everyone dreads. For a healthier approach, see our standup tools and async alternatives.

5. Status report to the Scrum Master

What it looks like: Team members face the Scrum Master or manager and report what they did yesterday. The conversation flows up, not sideways. Developers aren't talking to each other. Why it's harmful: The standup becomes a mini-performance review instead of a coordination tool. People optimize their updates for sounding productive rather than surfacing blockers. The team misses opportunities to help each other because they're performing, not communicating. How to fix it: The Scrum Master should step back physically and verbally. Literally stand outside the circle. Direct questions to "what does the team need to know?" instead of "what did you do?" Walking the board (discussing tickets from right to left) naturally shifts the focus from people to work.

6. Going over 15 minutes

What it looks like: The standup regularly runs 25, 30, sometimes 45 minutes. Problem-solving and design discussions break out. People start bringing laptops. Why it's harmful: Long standups are a tax on the entire team's morning. They signal that the meeting has no discipline, which invites even more drift. Team members start multitasking or checking out mentally. The people who weren't involved in the side conversation just lost 30 minutes for nothing. How to fix it: Use a visible timer. When a topic needs deeper discussion, note it and schedule a follow-up with only the people who need to be involved. The phrase to use: "Let's take that offline after standup."

7. Problem-solving in standup

What it looks like: Someone mentions a blocker and the entire team spends 10 minutes debugging it together. Or a technical question sparks an architecture discussion. Why it's harmful: This conflates two different activities: synchronizing and collaborating. The standup is for identifying problems, not solving them. When problem-solving takes over, people who aren't involved sit idle, and the meeting becomes unpredictable in length. How to fix it: Train the team to use standup for surfacing, not solving. The format should be: "I'm blocked on X. I need help from [specific person]." Then those two people meet immediately after standup. The rest of the team gets back to work.

Illustrated retrospective meeting where a manager sits at the head of the table while team members look uncomfortable and silent, with blank sticky notes on the wall

8. Only the Scrum Master talks

What it looks like: The SM runs through each person's tickets, asks for updates, and narrates the board. Developers give one-word answers. The standup is functionally a one-person show. Why it's harmful: It strips developers of agency. When the SM drives the conversation, the team isn't self-organizing; they're being managed. It also means the SM becomes a single point of failure for coordination. If they're out sick, the standup falls apart. How to fix it: Rotate facilitation among team members. Or better yet, eliminate explicit facilitation entirely and let the team walk the board themselves. The SM should observe, note patterns, and bring systemic issues to the retrospective rather than micromanaging the daily sync.

Retrospective anti-patterns

The retrospective is supposed to be the engine of continuous improvement. When it breaks, the team stops learning. For a guide on running retros well, see how to run an effective agile retrospective, and try our retrospective tool for structured formats.

9. No action item follow-through

What it looks like: The team identifies good improvements during the retro. Action items get written on sticky notes. Two weeks later, nobody remembers what they were. The next retro surfaces the same problems. Why it's harmful: This is the single fastest way to kill retrospective engagement. When people see their suggestions disappear into a void, they stop making them. The retro becomes a venting session with no consequences, and eventually, people stop attending mentally (even if they're physically present). How to fix it: Limit action items to two or three per retro. Assign a specific owner to each one. Start the next retrospective by reviewing the previous sprint's action items before anything else. Track completion visibly. If an action item can't be completed in one sprint, it's too big. Break it down.

The action item trap

More action items doesn't mean a better retro. Teams that produce 8-10 action items per session almost never complete most of them. Two completed improvements beat ten forgotten ones.

10. Same format every sprint

What it looks like: Every retrospective uses the same format. Start/Stop/Continue. Every. Single. Sprint. The team knows exactly what to expect and has stopped thinking critically about their answers. Why it's harmful: Familiarity breeds autopilot. When the format never changes, team members pre-compute their responses before the meeting starts. They stop discovering new insights because the questions aren't pushing them to think differently. The retro becomes a checkbox exercise. How to fix it: Rotate retrospective formats. Use the Sailboat one sprint, the 4Ls the next, then a timeline exercise. Each format surfaces different kinds of insights. Our retrospective ideas post has a library of formats to choose from. The variety itself signals that this meeting matters enough to invest in.

11. Manager attendance killing honesty

What it looks like: A manager or stakeholder sits in on the retrospective. The team discusses only safe topics: standup times, tooling preferences, meeting room acoustics. Nobody mentions the real problems. Why it's harmful: Retrospectives require vulnerability. People need to name failures, call out process breakdowns, and sometimes address interpersonal friction. None of that happens when someone with authority over their career is in the room. The team shifts to "success theater" and the real issues stay hidden. This is a textbook case of how low psychological safety silently undermines agile ceremonies. How to fix it: Managers should not attend retrospectives unless the team unanimously invites them. If organizational culture requires management visibility, share a summary of action items (not the raw discussion) after the retro. The Scrum Master's job is to protect this boundary.

12. The "everything is fine" retro

What it looks like: Nobody raises any concerns. The team agrees things are going well. The retro ends in 10 minutes. But sprint metrics tell a different story: missed commitments, rising cycle times, growing tech debt. Why it's harmful: "Everything is fine" is almost never true. It usually means one of three things: the team doesn't trust the environment enough to speak up, the retro format isn't surfacing real issues, or the team has given up on improvement because past suggestions were ignored. How to fix it: Start with data, not feelings. Show the sprint's actual metrics: velocity trend, items carried over, bugs escaped, cycle time. Let the numbers start the conversation. Use anonymous input collection before the retro so people can raise sensitive topics without attaching their name. And revisit whether anti-patterns 9 and 11 are at play.

Sprint review anti-patterns

The sprint review is the team's chance to get real feedback from stakeholders. When it turns into a one-way presentation, that feedback loop closes. For a complete guide to healthy reviews, see how to run a sprint review.

13. Demo only, no feedback

What it looks like: The team presents a polished demo of completed work. Stakeholders watch, nod, applaud. Nobody asks questions or suggests changes. The meeting ends with "great work, team." Why it's harmful: The sprint review isn't a demo. It's an inspect-and-adapt event. If stakeholders aren't providing feedback, the team is building in a vacuum. Misaligned expectations compound over multiple sprints until a major course correction becomes inevitable (and expensive). How to fix it: Structure the review around questions, not presentations. After each increment is shown, explicitly ask: "Does this match what you expected? What would you change? What should we prioritize next?" Give stakeholders the product to interact with, not just watch. Send the demo ahead of time so the meeting can focus on discussion.

14. No stakeholders attend

What it looks like: The sprint review is attended only by the Scrum team. No customers, no users, no business stakeholders. The PO sometimes plays the role of all three. Why it's harmful: Without external perspectives, the team loses touch with real user needs. The PO becomes a bottleneck for all feedback, and their assumptions go unchallenged. The team builds what the PO thinks users want instead of validating directly. How to fix it: Make stakeholder attendance easy. Send calendar invites early. Keep the meeting short and focused. Share a one-page agenda showing what will be reviewed. If key stakeholders truly can't attend, record the review and collect async feedback. But persistent non-attendance is a signal that the organization doesn't value the Scrum process, which is a problem worth escalating.

15. The PO approves or rejects work

What it looks like: The sprint review becomes an acceptance gate. The PO reviews each item and stamps it as "accepted" or "rejected," often with last-minute change requests. Why it's harmful: This turns the sprint review into a quality inspection rather than a collaborative discussion. It creates an adversarial dynamic between the PO and the team. It also means the Definition of Done isn't doing its job. If "done" items can be rejected, the team's definition of done is unclear, or the PO is adding new requirements disguised as acceptance criteria. How to fix it: Acceptance should be continuous, not batched into the review. The PO should be reviewing increments throughout the sprint, not saving it for a single ceremony. The sprint review should focus on strategic direction and stakeholder feedback, not on gatekeeping individual items.

Organizational anti-patterns

Some anti-patterns don't belong to any single ceremony. They infect the entire process.

🧟Zombie Scrum

The team goes through every motion of Scrum, but nothing meaningful comes out. Sprints produce increments nobody uses. Stakeholders have stopped paying attention. The team has lost any sense of purpose. The ceremonies happen, but they're hollow. This often stems from alack of psychological safetycombined with organizational dysfunction that the team feels powerless to address.

🔧Hardening sprints

The team dedicates entire sprints to "stabilization" or "hardening," fixing bugs and paying down tech debt accumulated during "feature sprints." This is a direct symptom of a broken Definition of Done. If quality work is only done in special sprints, quality is not part of the process. Build testing, refactoring, and documentation into every sprint.

📊Velocity as a performance metric

Management uses velocity to compare teams, evaluate individual performance, or set targets. The team responds predictably: they inflate estimates. A 5-point story becomes an 8. Velocity goes up. Actual output doesn't. For metrics that actually reveal process health, look atflow metrics like cycle time and throughputinstead.

How to diagnose your team

If you're unsure which anti-patterns apply to your team, use this checklist as a health assessment. Go through it honestly, ideally as a team during a retrospective.

Our sprint has a clear, articulated goal that the whole team can explain.

Developers choose their own sprint scope based on capacity, not assignments from the PO.

Backlog items are estimated before they enter sprint planning.

We complete 80% or more of our sprint commitment consistently.

Our standup stays under 15 minutes and focuses on coordination, not status.

Team members talk to each other in standup, not just to the Scrum Master.

Our retrospective action items from last sprint were completed.

People raise real concerns in retrospectives, not just logistics.

Stakeholders attend sprint reviews and provide actionable feedback.

We never have dedicated "bug fix" or "hardening" sprints.

Velocity is used for planning, not for performance evaluation.

The team's Definition of Done includes testing and documentation.

Any unchecked item points to an anti-pattern worth addressing. Start with the one that causes the most pain and fix it before moving on. Trying to fix everything at once is its own anti-pattern.

Wrapping up

Anti-patterns are insidious because they feel like process. The team is doing Scrum, running every ceremony, filling out every field in Jira. But the outcomes aren't there. Recognizing the pattern is the first step. Fixing it requires honesty about what's actually happening in the room and the organizational courage to change it. Start with one. Fix it. Prove it works. Then tackle the next one. That's how continuous improvement is supposed to work, one sprint at a time. If you're looking for tools that support healthier scrum ceremonies, Kollabe provides planning poker with anonymous estimation, retrospectives with structured formats, and async standups that keep distributed teams aligned.

An anti-pattern is a practice that appears productive or follows Scrum's structure on the surface but actually undermines the team's ability to deliver value. Anti-patterns often develop gradually as teams find shortcuts or fall into habits that circumvent the intent behind Scrum's events and roles.

Zombie Scrum describes teams that go through all the motions of Scrum without any of the outcomes. Sprints happen, ceremonies run on schedule, and boards get updated, but the team has lost connection to stakeholders, purpose, and the ability to inspect and adapt. The term was popularized by Johannes Schartau, Christiaan Verwijs, and Barry Overeem. It's typically caused by a combination of organizational dysfunction, low psychological safety, and a disconnect between the team and the people using their product.

Start with the retrospective. It's the one ceremony explicitly designed for process improvement. Raise the specific anti-pattern with data: show sprint metrics, point to patterns across multiple sprints, and propose a concrete experiment to try for one sprint. Frame it as a hypothesis, not a complaint. If retrospective anti-patterns are the problem (patterns 9-12), that's a conversation for the Scrum Master, who has the organizational mandate to protect the team's ability to inspect and adapt.

Yes, in the short term. Teams can ship features while running broken standups, skipping retro action items, and overcommitting every sprint. But it's not sustainable. Anti-patterns create hidden costs: burnout, technical debt, eroding trust, and turnover. The damage compounds over time. Teams that address anti-patterns early protect their long-term velocity and team health.