Common Pitfalls for New Scrum Teams: What to Watch For and How to Respond

How to Use This Chapter

When something feels “off” in a Sprint, name the symptom you observe, consider the likely cause, then propose a practical correction you can try immediately. The goal is not to blame people; it’s to restore transparency, focus, and flow with small, low-bureaucracy adjustments.

Pitfall 1: Unclear Sprint Goal

Symptom

• People can’t explain the Sprint Goal in one sentence.
• Daily discussions revolve around tasks, not outcomes.
• When something slips, nobody knows what to drop.

Likely cause

• The Sprint Goal was written as a list of items or a vague theme (“Improve performance”).
• Work was selected before agreeing on the outcome.
• Multiple competing priorities were packed into one Sprint.

Practical correction

• Rewrite the Sprint Goal as an outcome (what changes for users or the business) and a boundary (what’s explicitly not required).
• Create a “trade list”: mark 1–2 backlog items as optional so the team has a pre-agreed scope lever.
• Daily check: ask “Does today’s plan increase the chance we meet the Sprint Goal?” If not, renegotiate tasks.

Step-by-step: Re-anchoring mid-Sprint (10 minutes)

1. State the current Sprint Goal in one sentence. If you can’t, draft a clearer version.
2. List the remaining work that directly supports that goal.
3. Identify work that doesn’t support it (or is lower value) and propose dropping/de-scoping it.
4. Confirm the trade with the Product Owner (PO) and update the Sprint Backlog.

Respectful script

“I’m not sure I can connect some of our current tasks to the Sprint Goal. Could we restate the goal in one sentence and confirm which items are essential vs optional?”

Pitfall 2: Partial Completion (“Almost Done” Everywhere)

Symptom

• Many items are “in progress” late in the Sprint.
• Testing/review piles up at the end.
• Work is handed off between specialists and waits in queues.

Likely cause

• Items are too large or have hidden acceptance/quality steps.
• Too much work started at once (high WIP).
• Swarming/pairing is avoided; people optimize for being “busy.”

Practical correction

• Finish-first rule: don’t start new work while older work is stuck.
• Slice remaining work into smaller vertical increments that can be completed end-to-end.
• Swarm on the oldest item (especially anything close to “done”).

Step-by-step: Unblocking a nearly-done item

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

1. Pick the item closest to completion that still blocks the Sprint Goal.
2. List the remaining steps explicitly (e.g., review, test, documentation, deployment check).
3. Assign 2–3 people to swarm until it meets the team’s “done” criteria.
4. Only then pull the next item.

Small process adjustment (low bureaucracy)

• Add a simple WIP limit like: “Max 2 items per person in progress; prefer 1.”
• Add a “Ready for Review/Test” lane and make it visible when it grows.

Respectful script

“We have several items at 90%. If we swarm on the oldest one and finish it today, we’ll reduce risk and free capacity. Can we pause starting new work until we clear this?”

Pitfall 3: Hidden Work (Untracked Tasks and Side Requests)

Symptom

• People are busy but Sprint items don’t move.
• Support, fixes, and “quick favors” appear in chat and never show up on the board.
• Surprise work shows up during the Sprint Review.

Likely cause

• No clear intake policy for urgent work.
• Fear that making work visible will be judged.
• Work is split across tools (tickets, emails, DMs) without consolidation.

Practical correction

• Make all work visible: if it takes more than a few minutes, it becomes a tracked item.
• Create an “expedite” path: define what qualifies as urgent and who approves it (usually PO, with team input).
• Timebox support: reserve a small capacity buffer if support is predictable.

Step-by-step: Handling a “quick request”

1. Ask for the request in writing (one sentence outcome + why it’s urgent).
2. Create a visible item (even a small task) and link it to the requester.
3. Ask the PO to decide: swap it with existing scope or schedule it next.
4. Update the board so the team can adapt.

Respectful script

“Happy to help. To keep our Sprint transparent, can we add this as a small ticket and confirm with the PO what we should de-scope to make room?”

Pitfall 4: Dependencies That Stall Progress

Symptom

• Items are blocked waiting on another team, vendor, environment, or approval.
• Work starts but can’t be finished end-to-end.
• Daily updates repeat “still waiting.”

Likely cause

• Dependencies weren’t identified early enough.
• Integration points are unclear (APIs, data contracts, access).
• External teams have different priorities and timelines.

Practical correction

• Expose dependencies immediately and track them as explicit blockers.
• Negotiate a thin vertical slice that reduces dependency surface area (e.g., mock/stub, feature toggle, simplified integration).
• Set a response deadline and a fallback plan (what you’ll do if no response by date X).

Step-by-step: Dependency handshake

1. Write a one-paragraph request: what you need, by when, and why.
2. Propose the smallest acceptable deliverable (e.g., sample payload, endpoint contract, access role).
3. Ask for confirmation of owner and date.
4. If not confirmed within 24–48 hours, raise it as an impediment to the Scrum Master (SM) and inform the PO of impact on scope.

Respectful script

“This item is blocked on Team X’s API contract. If we don’t have it by Wednesday, we can’t complete the Sprint Goal. Can we agree on an owner and a date, and in parallel decide a fallback (stub or reduced scope)?”

Pitfall 5: Mid-Sprint Scope Changes

Symptom

• New requirements appear after Sprint starts and are treated as mandatory.
• Work is added without removing anything.
• The team feels whiplash; priorities shift daily.

Likely cause

• Stakeholders bypass the PO and go directly to Developers.
• The organization confuses “being agile” with “changing everything anytime.”
• The Sprint Goal is not used as a decision filter.

Practical correction

• Route changes through the PO and evaluate impact against the Sprint Goal.
• Use explicit trade-offs: add X only if we remove Y.
• Protect focus: if the change threatens the Sprint Goal, propose scheduling it for the next Sprint unless it’s truly urgent.

Step-by-step: Responding to a change request

1. Clarify the request outcome and urgency (“What happens if we wait until next Sprint?”).
2. Estimate impact quickly (rough size, risks, who is needed).
3. Ask the PO to decide: swap scope, adjust the Sprint Goal, or defer.
4. Update the Sprint Backlog and communicate the trade clearly.

Respectful script (to a stakeholder)

“Thanks—this sounds valuable. We’re mid-Sprint and committed to the Sprint Goal. Could you share this with the PO so we can decide whether to swap it with something else or plan it for next Sprint?”

Respectful script (to the PO)

“We received a new request that may be urgent. If we take it in, I think we need to drop [item] to keep the Sprint Goal achievable. How would you like to proceed?”

Pitfall 6: Weak Refinement (Work Isn’t Ready When Needed)

Symptom

• Sprint Planning is slow because items are unclear.
• Developers discover missing acceptance details mid-Sprint.
• Items bounce back and forth due to ambiguity.

Likely cause

• Refinement is skipped or treated as optional.
• Items are brought in without clear examples, constraints, or test considerations.
• Too many items are “half-baked” instead of a few being “ready enough.”

Practical correction

• Define a lightweight “ready check” (not heavy documentation): clear intent, key acceptance examples, known dependencies, and size small enough to finish.
• Refine just-in-time: keep 1–2 Sprints worth of upcoming items in a healthy state, not the whole backlog.
• Invite the right people: include someone who can answer domain questions and someone who thinks about testing/validation.

Step-by-step: 15-minute micro-refinement

1. Pick the next highest-priority item likely to enter a Sprint soon.
2. Ask: “What problem does this solve, and for whom?”
3. Add 2–3 concrete acceptance examples (inputs/outputs, edge cases).
4. Identify unknowns and create 1–2 spike/tasks to resolve them if needed.
5. Confirm it’s small enough; if not, split into a thinner slice.

Small process adjustment (low bureaucracy)

• Add a checklist on the card: Intent clear, Examples added, Dependencies noted, Small enough.

Respectful script

“Before we pull this into a Sprint, can we add a couple of concrete examples and call out any dependencies? I’m worried we’ll discover gaps mid-Sprint.”

Pitfall 7: Poor Stakeholder Engagement (Feedback Arrives Too Late)

Symptom

• Sprint Reviews are poorly attended or become status meetings.
• Feedback comes weeks later, after decisions are “locked in.”
• The team builds features that are technically correct but miss expectations.

Likely cause

• Stakeholders don’t see the value of attending or don’t know what’s expected.
• Feedback channels are unclear; stakeholders don’t feel heard.
• Increments aren’t easy to view (hard to access environments, no demo path).

Practical correction

• Make feedback easy: provide a simple demo path and a short list of questions you want answered.
• Timebox and focus: show only what’s relevant to decisions; avoid long slide decks.
• Follow up with specific asks: who decides what, by when.

Step-by-step: Improving feedback in the next Review

1. Before the Review, send a 3-bullet agenda: what will be shown, what decisions are needed, what options exist.
2. During the Review, demo the increment and ask targeted questions (e.g., “Which workflow is preferred: A or B?”).
3. Capture feedback as backlog items with clear owners for next steps.
4. After the Review, send a short recap with decisions and open questions.

Respectful script

“We’d really value your input on this workflow. In the Review, could you help us decide between option A and B? It will prevent rework next Sprint.”

Pitfall 8: Definition of Done (DoD) Erosion

Symptom

• Items are marked “done” with known defects or missing tests.
• Quality steps are skipped to “hit the Sprint.”
• Rework and bug-fixing consume future capacity.

Likely cause

• Schedule pressure outweighs quality discipline.
• DoD is treated as negotiable or “aspirational.”
• Testing/review capacity is constrained, creating end-of-Sprint crunch.

Practical correction

• Stop-the-line mindset: if an item can’t meet DoD, it’s not done—adjust scope rather than quality.
• Shift quality left: test/review earlier by keeping items small and limiting WIP.
• Make quality work visible: tests, automation, and refactoring are first-class tasks, not invisible extras.

Step-by-step: When someone suggests “just mark it done”

1. State the specific DoD gap (e.g., “No automated test,” “Not deployed to staging,” “No code review”).
2. Offer options: (a) finish the missing step now by swarming, (b) de-scope part of the item, or (c) keep it incomplete and re-plan.
3. Confirm the decision transparently with the team and PO.

Respectful script

“I’m concerned we’re about to weaken our DoD. If we mark this done without [missing step], we’ll likely pay for it next Sprint. Can we either swarm to finish it properly or de-scope and keep it not done?”

Raising Concerns Respectfully (Scripts You Can Reuse)

Use neutral observations, name impact, and propose a next step. Avoid “you/they” language; prefer “I notice,” “we,” and “the work.”

• Observation → impact → request: “I notice [fact]. I’m worried it will cause [impact]. Can we try [request]?”
• Clarify urgency: “What happens if we don’t do this until next Sprint?”
• Trade-off framing: “If we add this, what should we remove to keep our goal realistic?”
• Invite alignment: “Can we confirm what ‘success’ looks like for this Sprint?”

Escalating Impediments Without Drama

When to escalate

• A blocker persists beyond one day with no clear owner or plan.
• The blocker threatens the Sprint Goal or forces DoD compromise.
• The team lacks authority to resolve it (access, approvals, cross-team commitments).

How to escalate (practical steps)

1. Describe the impediment in one sentence (what is blocked).
2. State impact: which item(s) and how it affects the Sprint Goal.
3. State what you already tried (who you contacted, when).
4. Propose options: workaround, de-scope, or external action needed.
5. Ask for a decision/owner: who will do what by when.

Escalation script (to Scrum Master)

“We’re blocked on [impediment]. It impacts [item] and risks the Sprint Goal because [impact]. We tried [actions] and are waiting on [person/team]. Can you help secure an owner and a response by [date/time], or help us agree on a workaround?”

Escalation script (to PO, focusing on scope/value)

“Given the blocker, we may not finish [item]. Options are: (1) de-scope [part], (2) swap in [alternative], or (3) adjust expectations for the Sprint Goal. Which option best protects value?”

Small Adjustments That Improve Flow (Without Adding Bureaucracy)

1) Add a “Blocked” signal and a rule

• Rule: if blocked for more than 24 hours, it must be raised explicitly and an owner assigned to resolve it.

2) Use a simple “intake agreement” for mid-Sprint requests

• Rule: any new request must be visible and requires a trade-off decision (swap/defer) with the PO.

3) Create a “finish lane” and protect it

• Rule: at least one person focuses on moving items from “almost done” to “done” each day.

4) Keep refinement lightweight but consistent

• Rule: refine 1–3 upcoming items weekly with a short ready check; avoid large documents.

5) Make stakeholder feedback a repeatable habit

• Rule: every Review includes 2–3 explicit questions that require stakeholder input, captured as follow-up items.

6) Protect DoD by reducing WIP, not by negotiating quality

• Rule: if quality steps are at risk, stop starting new work and swarm to complete fewer items properly.