Common Scrum anti-patterns include working without a meaningful Sprint Goal, turning the Daily Scrum into a manager status meeting, allowing the Product Owner to dictate the Sprint Backlog, carrying unfinished work from Sprint to Sprint, treating velocity as a performance target, skipping stakeholder feedback, cancelling retrospectives and expecting the Scrum Master to behave like a project coordinator or team boss.
These behaviours do not usually begin with bad intent. They often emerge when organisations want predictability, leaders fear uncertainty, teams lack product direction or Scrum accountabilities are misunderstood. The Scrum Master fixes anti-patterns by making the consequences visible, protecting empiricism, coaching the Scrum Team and organisation, facilitating focused experiments and removing systemic impediments. The goal is not mechanical compliance. The goal is better transparency, inspection, adaptation and value delivery.
What Is a Scrum Anti-Pattern?
A Scrum anti-pattern is a recurring response to a real problem that appears helpful in the short term but damages agility over time. For example, a manager may assign every task to make planning faster. The team receives a plan, but self-management weakens, estimates become less honest and accountability moves away from the people doing the work. The visible problem is solved while the delivery system becomes more fragile.
- Recurring: A one-off mistake is a learning event. An anti-pattern becomes normal behaviour.
- Locally rational: The behaviour often solves an immediate pressure, such as a deadline, executive request or lack of clarity.
- Systemically harmful: The pattern creates delayed feedback, hidden risk, low ownership, poor quality or reduced trust.
- Observable: Warning signs appear in events, artefacts, language, metrics and stakeholder behaviour.
- Correctable: A Scrum Master can use coaching, facilitation, teaching and organisational change to restore healthy feedback.
Why Scrum Anti-Patterns Cause Agile Projects to Fail
- They hide reality: Optimistic status, incomplete work and manipulated metrics prevent evidence-based decisions.
- They delay feedback: Long batches, absent stakeholders and skipped reviews allow the team to build the wrong solution for longer.
- They reduce ownership: Task assignment and command-and-control behaviour teach team members to wait for direction.
- They increase technical debt: Pressure to start more work and weaken the Definition of Done creates fragile products and slower future delivery.
- They damage trust: Blame, surveillance and ignored commitments make people protect themselves instead of sharing problems.
- They confuse output with value: A busy backlog and rising velocity can coexist with poor customer outcomes.
- They exhaust the team: Chronic overcommitment, interruptions and unsustainable pace lead to burnout and turnover.
Scrum Anti-Patterns at a Glance
| Anti-pattern | Warning sign | Damage | Scrum Master response |
| No Sprint Goal | Sprint is a list of unrelated tickets. | No shared purpose or adaptation rule. | Facilitate a goal before selecting work. |
| Daily status meeting | Developers report to a manager. | Low collaboration and hidden blockers. | Return focus to inspecting progress and adapting the plan. |
| PO dictates scope | Work is assigned without negotiation. | Overcommitment and weak ownership. | Teach accountability boundaries and facilitate planning. |
| Mini-waterfall Sprint | Analysis, development and testing happen in sequence. | Late feedback and carry-over. | Encourage thin vertical slices and shared work. |
| Velocity target | Teams are compared by points. | Gaming, inflation and quality loss. | Replace targets with outcome and flow conversations. |
| Review as demo theatre | Only finished slides and applause. | No meaningful stakeholder adaptation. | Design the review around evidence and decisions. |
| Retrospective cancelled | Improvement work disappears under pressure. | Problems repeat and trust declines. | Protect the event and track one experiment. |
| Scrum Master as boss | Scrum Master assigns tasks and approves work. | Self-management disappears. | Coach, facilitate and remove system impediments. |
| Done means almost done | Testing or deployment remains outside the Sprint. | Hidden work and unreliable increments. | Strengthen the Definition of Done. |
| Constant interruption | Urgent work enters without trade-offs. | Sprint Goal loses meaning. | Create an explicit path for genuine emergencies. |
25 Common Scrum Anti-Patterns and How Scrum Masters Fix Them
1. Starting a Sprint Without a Meaningful Sprint Goal
The team fills capacity with the highest-ranked Product Backlog items but cannot explain why the Sprint matters. Every item looks equally important, so mid-Sprint trade-offs become political. The Scrum Guide defines the Sprint Goal as the single objective for the Sprint and the commitment for the Sprint Backlog. Without it, the Sprint becomes a short project plan rather than a coherent value experiment.
How the Scrum Master fixes it: Ask the Product Owner to explain the intended outcome before discussing volume. Facilitate Developers and the Product Owner to create one concise objective, then select and shape work that supports it. During the Sprint, use the goal to decide whether a change helps or threatens the objective.
2. Product Owner Dictates the Sprint Backlog
The Product Owner enters Sprint Planning with a fixed list and treats Developers as recipients of scope. Estimates are accepted under pressure, and people stop challenging assumptions. The Product Owner is accountable for ordering the Product Backlog, while Developers are accountable for creating the Sprint Backlog and plan.
How the Scrum Master fixes it: Teach the distinction between priority and plan. Ask Developers what is realistic under the Definition of Done, current capacity and known risks. Make trade-offs explicit. If leadership has imposed a date, facilitate an options conversation about scope, quality, risk and evidence rather than forcing false certainty.
3. Sprint Planning Becomes a Marathon Estimation Session
Backlog items arrive vague, oversized or unexamined. The team spends most of planning debating details and has little energy left to discuss the Sprint Goal or delivery approach.
How the Scrum Master fixes it: Improve ongoing Product Backlog refinement without creating a mandatory mini-ceremony. Encourage small, understandable items and early technical discussion. Timebox unresolved debates, record the question and involve the right expert. Planning should create a valuable Sprint Goal and a credible plan, not perfect foresight.
4. The Daily Scrum Is a Status Report to the Scrum Master
Team members answer what they did, what they will do and whether they are blocked while looking at the Scrum Master or manager. Collaboration happens after the meeting, and the Sprint Backlog is not adapted.
How the Scrum Master fixes it: Step out of the centre. Remind Developers that the Daily Scrum is their 15-minute event to inspect progress toward the Sprint Goal and adapt the plan. Experiment with walking the work board, focusing on the oldest item or asking what must change today to protect the goal.
5. The Daily Scrum Runs for 45 Minutes
Detailed problem-solving, design debates and stakeholder questions consume the event. People disengage because most discussion does not require everyone.
How the Scrum Master fixes it: Protect the purpose and timebox. Capture topics that need follow-up, identify necessary participants and continue immediately afterward. The goal is not to silence useful discussion. It is to separate team-wide daily planning from deeper problem-solving.
6. The Scrum Master Is a Ticket Administrator
The Scrum Master updates boards, chases status, writes every minute and moves work for Developers. The organisation sees the role as administrative support.
How the Scrum Master fixes it: Return ownership to the team. Developers should maintain the Sprint Backlog because it represents their plan. The Scrum Master should invest time in facilitation quality, impediment removal, coaching, product collaboration and organisational barriers rather than becoming the team’s personal assistant.
7. The Scrum Master Acts as Team Manager
Tasks are assigned, leave is approved, estimates are challenged and individual performance is judged by the Scrum Master. Team members wait for instructions.
How the Scrum Master fixes it: Clarify that the Scrum Master is accountable for the Scrum Team’s effectiveness, not positional control over people. Use coaching questions, make work transparent and help Developers design their own coordination. Escalate only genuine organisational impediments while preserving team decision-making.
8. The Product Owner Is Absent or Has No Authority
Developers cannot get timely answers, stakeholders bypass the Product Owner and the Product Backlog becomes a collection of competing requests. Decisions are repeatedly reopened.
How the Scrum Master fixes it: Make decision latency visible. Coach the organisation to provide one accountable Product Owner with access, authority and time. Establish practical collaboration windows and clear stakeholder channels. Do not let the Scrum Master quietly become a substitute Product Owner.
9. The Product Backlog Is a Requirements Warehouse
Thousands of stale items sit in the backlog. Ordering reflects age, politics or whoever shouted last. The Product Goal is invisible, and refinement focuses on wording rather than value.
How the Scrum Master fixes it: Use the Product Goal as a filter. Remove obsolete items, group work around outcomes and clarify near-term choices. Support the Product Owner in saying no, gathering evidence and keeping the Product Backlog transparent, ordered and appropriately detailed.
10. User Stories Become Mandatory Forms
Every requirement is forced into “As a user” wording even when it adds no clarity. Teams debate grammar instead of customer need, conditions and evidence.
How the Scrum Master fixes it: Teach that user stories are an optional technique, not a Scrum artefact. Use the representation that best supports understanding. Focus discussion on user, problem, value, examples, constraints and how the team will know the result works.
11. The Sprint Is a Mini-Waterfall
Analysts work first, developers work in the middle and testers receive a large batch near the end. Work is frequently “code complete” but not Done.
How the Scrum Master fixes it: Facilitate thin vertical slices that include analysis, build, test and integration. Encourage swarming, shared skills and early testing. Use the Definition of Done to reveal remaining work. Reduce batch size before adding more process.
12. Work Is Carried Over Automatically
Unfinished items roll into the next Sprint without inspection. The team counts partial points or treats carry-over as normal.
How the Scrum Master fixes it: Do not normalise unfinished work. At the end of the Sprint, inspect what is actually Done. Unfinished items return to the Product Backlog for Product Owner ordering. In the retrospective, examine size, dependencies, quality, interruptions and planning assumptions, then choose a small experiment.
13. The Definition of Done Is Weak or Optional
An item can be called done while testing, security, documentation, accessibility or deployment remains. Stakeholders see progress that cannot be released.
How the Scrum Master fixes it: Make hidden work visible and strengthen the Definition of Done gradually. Developers are accountable for quality through the Definition of Done. If organisational standards exist, incorporate them. Discuss capability investments needed to create a usable Increment each Sprint.
14. Velocity Becomes a Productivity Target
Managers compare teams by story points, demand higher velocity or assess individuals by completed tickets. Teams inflate estimates and avoid valuable work that looks slow.
How the Scrum Master fixes it: Explain that story points are a local planning aid, not a universal unit of value or performance. Stop cross-team comparisons. Shift conversations toward Sprint Goal success, customer outcomes, quality, lead time, learning and impediments.
15. Too Much Work in Progress
Every specialist starts a separate item to stay busy. Many items are nearly done, while few are finished. Testing and review become bottlenecks.
How the Scrum Master fixes it: Visualise work in progress and ageing items. Facilitate a team experiment to finish before starting, swarm on blocked work and reduce batch size. Reliability improves when flow is optimised for completed value rather than individual utilisation.
16. Stakeholders Interrupt the Sprint Directly
Executives and customers add urgent work through private messages. Developers accept changes without considering the Sprint Goal or Product Owner.
How the Scrum Master fixes it: Create a transparent route for requests through the Product Owner. Genuine emergencies still require inspection and a conscious trade-off. Teach stakeholders that protecting focus is not refusing collaboration. It is preserving a clear decision process.
17. Sprint Review Becomes Demo Theatre
The team presents polished slides, receives praise and closes the meeting. Real users, customers or decision-makers are absent. No one inspects market changes or adapts the Product Backlog.
How the Scrum Master fixes it: Design the Sprint Review as a working session. Invite relevant stakeholders, inspect the Increment and progress toward the Product Goal, discuss evidence and change, and leave with updated options. Demonstration is useful only when it creates feedback.
18. The Retrospective Is Cancelled When Work Is Late
Management treats reflection as optional overhead. The team uses the time to finish tasks, so the causes of lateness repeat.
How the Scrum Master fixes it: Protect the Sprint Retrospective as the formal opportunity to improve quality and effectiveness. Keep it focused, psychologically safe and practical. Select at least one improvement that can be acted on quickly and inspect the result in the next Sprint.
19. The Retrospective Becomes a Blame Session
People identify who made mistakes, action items target individuals and difficult details leave the room. Participation falls because honesty feels unsafe.
How the Scrum Master fixes it: Set working agreements, use neutral observations and explore systems, interactions and conditions. Separate accountability from humiliation. If serious conduct or performance matters exist, handle them through appropriate channels instead of disguising them as team improvement.
20. Retrospective Actions Disappear
The team creates a long action list, but no owner, measure or follow-up exists. The same themes appear every Sprint.
How the Scrum Master fixes it: Choose one small, testable improvement. Define who will start it, when it will be reviewed and what evidence will indicate progress. Place the improvement into the Sprint Backlog when appropriate so it competes honestly for capacity.
21. Technical Debt Is Invisible
Feature pressure dominates every Sprint. Defects, fragile tests, poor architecture and manual deployment slow the team, but the backlog shows only new functionality.
How the Scrum Master fixes it: Help Developers and the Product Owner connect technical health to value, risk and forecast. Make quality work visible, include it in planning and improve the Definition of Done. Use evidence such as incident frequency, cycle time and escaped defects without turning metrics into targets.
22. Specialists Create Silos
Only one person can test, deploy, design or understand a critical service. Work waits in queues and absence stops delivery.
How the Scrum Master fixes it: Encourage pairing, mentoring, shared documentation and deliberate skill development. Cross-functional does not mean everyone has identical skills. It means the Scrum Team can create value without depending on external hand-offs for every step.
23. The Team Is Reorganised Every Sprint
Managers move people between priorities to maximise utilisation. Relationships, product knowledge and working agreements never stabilise.
How the Scrum Master fixes it: Show the cost of context switching and team reset. Advocate stable, product-focused teams while allowing thoughtful change when necessary. Measure outcomes and flow rather than keeping every person separately busy.
24. Scrum Events Become Empty Calendar Rituals
The team attends every event but does not inspect or adapt anything. The process looks Agile while decisions remain command-driven.
How the Scrum Master fixes it: Reconnect each event to its purpose and commitment. Ask what decision became possible because the event occurred. Remove performative reporting, improve facilitation and ensure transparency is sufficient for honest inspection.
25. “ScrumBut” Hides Structural Problems
The organisation says, “We use Scrum, but we skip reviews,” or “We use Scrum, but managers assign all work.” Each exception protects the old operating model.
How the Scrum Master fixes it: Avoid policing language. Explore the problem the deviation is trying to solve, compare outcomes with Scrum’s intent and run an experiment that restores the missing feedback loop. Escalate systemic barriers with evidence and allies.
A Practical Anti-Pattern Diagnosis Framework
- Observe without blame: Record the behaviour, context and evidence. Avoid diagnosing motives.
- Identify the damaged feedback loop: Which transparency, inspection or adaptation opportunity is weakened?
- Connect to purpose: Which Scrum event, artefact, commitment or accountability is no longer serving its purpose?
- Find the system pressure: What incentive, fear, dependency, skill gap or policy makes the behaviour rational?
- Make impact visible: Show delay, rework, quality risk, decision latency or stakeholder confusion using simple evidence.
- Design one experiment: Change a small part of the system for one or two Sprints.
- Agree a measure: Use evidence such as Sprint Goal success, ageing work, defects, stakeholder decisions or action completion.
- Inspect and adapt: Keep, change or stop the experiment based on what happened.
Metrics That Help Without Becoming New Anti-Patterns
- Sprint Goal success: Did the team achieve the intended outcome, and what did the team learn?
- Work-item age: How long has active work remained unfinished?
- Cycle time: How long does work take from start to Done? Use distributions, not one misleading average.
- Escaped defects: What quality issues reached customers, and what system conditions allowed them?
- Planned versus unplanned work: How much capacity is disrupted, and which sources are recurring?
- Retrospective experiment completion: Did the team perform and inspect the chosen improvement?
- Stakeholder decision latency: How long do important product or risk decisions wait?
- Customer outcomes: Are use, satisfaction, revenue, risk reduction or service outcomes improving?
Metric safeguard: Never use one delivery metric to rank individuals or teams. When a measure becomes a target, people can optimise the number instead of the system. Combine quantitative trends with context, customer evidence and team discussion.
How Scrum Masters Build Organisational Support
- Coach leaders on empiricism: Explain why honest forecasts and visible uncertainty create better decisions than false certainty.
- Improve Product Owner access: Help sponsors delegate real decision authority and create clear stakeholder channels.
- Address dependencies: Work with other teams and managers to reduce hand-offs, queues and shared-service bottlenecks.
- Protect quality: Connect technical debt and weak Done criteria to incidents, cost, delay and reputation.
- Create safe escalation: Make it possible to surface risks early without punishing the messenger.
- Model Scrum values: Use commitment, focus, openness, respect and courage in difficult conversations.
- Develop facilitation capability: Teach teams to run events effectively instead of making every event dependent on one Scrum Master.
Scrum Anti-Patterns Across Australian Workplaces
- Sydney: Large financial services, consulting and technology programs often need help replacing status governance with evidence-based product decisions.
- Melbourne: Product, health, education, retail and enterprise teams benefit from stronger Product Goals, stakeholder reviews and cross-functional collaboration.
- Brisbane: Government, utilities, health and digital teams can use Scrum Masters to reduce dependencies and improve continuous feedback.
- Perth: Resources and distributed operations make stable teams, clear decision rights and asynchronous transparency especially important.
- Adelaide: Defence, government and technology programs may need to balance formal assurance with iterative learning and usable increments.
- Canberra: Public-sector and supplier teams benefit when governance, procurement and reporting support rather than replace empirical delivery.
- Hobart, Darwin and Gold Coast: Smaller or distributed teams can use live online training and disciplined facilitation to build consistent practice.
View Scrum Master certification locations across Australia
Do Scrum Masters Need Certification to Fix Anti-Patterns?
Certification does not automatically create coaching judgement, but structured learning can help practitioners understand Scrum accurately, separate official elements from optional techniques and practise facilitation. A useful course should go beyond exam definitions and give learners scenarios involving conflict, Product Owner availability, Sprint Goals, backlog decisions, metrics, quality and organisational impediments.
Recommended internal course links: Browse Scrum Master courses | View iSQI Scrum Master Pro Certification | Read Scrum Master training FAQs
Frequently Asked Questions
What are the most common Scrum anti-patterns?
Common examples include no Sprint Goal, status-report Daily Scrums, dictated scope, large batches, weak Definition of Done, velocity targets, absent stakeholders, cancelled retrospectives and command-and-control Scrum Masters.
Why do Agile projects fail even when teams use Scrum?
Teams may copy events and titles while preserving old incentives, silos, approval delays and output targets. Scrum exposes problems, but the organisation must act on what becomes visible.
How does a Scrum Master fix a failing team?
The Scrum Master observes evidence, clarifies Scrum’s purpose, creates safe conversations, facilitates one improvement experiment and addresses organisational impediments. The Scrum Master does not take over the team’s work.
Is the Daily Scrum a status meeting?
No. The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. Other people may attend, but the event should not become reporting to a manager.
Who decides what enters the Sprint?
The Product Owner orders the Product Backlog and explains value. Developers select and plan work they believe can support the Sprint Goal under the Definition of Done.
Should unfinished work move automatically to the next Sprint?
No. Work that does not meet the Definition of Done is not part of the Increment. It returns to the Product Backlog for Product Owner ordering.
Is velocity a good KPI?
Velocity can help one team with local forecasting, but it is unsafe for comparing teams or judging productivity. Story points are subjective and can be gamed.
Can a Scrum Master cancel a retrospective?
Cancelling the retrospective removes the formal opportunity to improve quality and effectiveness. Under pressure, reflection becomes more important because recurring system problems need attention.
What is ScrumBut?
ScrumBut describes claiming to use Scrum while repeatedly excluding or changing core elements, often to preserve an existing organisational habit.
Where can I study Scrum Master certification in Australia?
Scrum Master Certification Australia lists instructor-led options in Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra and live virtual formats, with additional city availability on course pages.
Final Takeaway
Common Scrum anti-patterns cause Agile projects to fail because they weaken the feedback loops that Scrum is designed to create. The most effective Scrum Masters do not shame teams or enforce ceremonies mechanically. They help people see reality, understand the purpose behind Scrum, change one system condition at a time and inspect whether value, quality and collaboration improve. Healthy Scrum is visible when the team has a clear goal, creates a Done Increment, learns with stakeholders and becomes increasingly capable of managing its own work.
Ready to strengthen practical Scrum leadership? Compare Scrum Master certification courses and request information