Daily Scrum: Inspecting Progress Toward the Sprint Goal

Purpose: Inspect Progress and Adapt the Plan

The Daily Scrum is a short, daily event for Developers to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours. The key output is a shared, updated plan: who is doing what next, what sequence makes sense, and what risks need attention. It is not a reporting meeting; it is a coordination and decision-making moment focused on finishing valuable work and meeting the Sprint Goal.

Think of it as answering one question together: “Given where we are right now, what is the best plan to move closer to the Sprint Goal today?”

What “inspect and adapt” looks like in practice

• Inspect: Compare current reality (work completed, work in progress, new information) against the Sprint Goal and the remaining work.
• Adapt: Adjust the daily plan: reorder tasks, swarm on a stuck item, split work to reduce risk, or negotiate scope within the Sprint (without changing the Sprint Goal).

Recommended Format Options (Choose What Fits Your Team)

The Scrum Guide does not mandate a script. Use a format that keeps the discussion anchored to the Sprint Goal and the work.

Option A: Board-walk (work-item focused)

Walk the board from right to left (closest to “Done” first). The goal is to finish work, not start more work.

• Start with items in Review/Testing or “Almost Done”: What is needed to get them to Done today?
• Then look at In Progress: Is anything stuck? Is WIP too high?
• Only then look at To Do: What should be pulled next, and by whom?

Why it works: It naturally drives flow, reduces work in progress, and surfaces bottlenecks early.

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

Option B: Sprint Goal-focused discussion (outcome focused)

Start by restating the Sprint Goal in one sentence, then discuss what must happen today to move it forward.

• What evidence do we have that we are on track?
• What is the biggest risk to the Sprint Goal right now?
• What is the single most valuable thing we can finish today?

Why it works: It keeps the team aligned when there are many tasks, dependencies, or shifting priorities.

Option C: Hybrid (board-walk + goal check)

Open with a 30-second Sprint Goal check, then do a quick board-walk. Many teams find this balances focus and practicality.

Timeboxing: Keeping It Short and Useful

The Daily Scrum is timeboxed to 15 minutes for a one-month Sprint (and typically remains 15 minutes for shorter Sprints). The timebox is a constraint that forces clarity and prioritization.

Step-by-step to run an effective 15-minute Daily Scrum

1. Start on time (even if someone is missing). Late starts train the team to arrive late.
2. Anchor on the Sprint Goal (one sentence) or start at the right side of the board.
3. Focus on finishing: identify what can reach Done today and who will help.
4. Call out risks/blockers briefly and decide the next action (not the full solution).
5. Confirm the plan for the next 24 hours: assignments, pairing, handoffs, and expected outcomes.
6. Park deeper topics for follow-up conversations immediately after with the right people.

Practical time management tactics

• Use a visible timer and a “parking lot” list for topics that need more time.
• Limit updates to what changes the plan. If it doesn’t affect today’s plan, it’s probably not needed in the meeting.
• Prefer decisions over narration: “I’ll pair with Sam to finish the failing test” is more useful than “I worked on tests yesterday.”

What to Bring: The Inputs That Make the Meeting Valuable

Come prepared with information that helps the team adapt the plan. You do not need a speech; you need clarity.

Bring your progress in terms of outcomes

• What moved closer to Done since yesterday?
• What is the next smallest step to move it closer to Done today?
• What is still uncertain (e.g., an assumption that needs validation)?

Bring risks and blockers early

A blocker is anything that prevents progress; a risk is anything that might prevent progress. Mention both, but keep it actionable.

• Blocker example: “Cannot deploy to the test environment; access is missing.”
• Risk example: “The API response time is slower than expected; performance might fail acceptance checks.”

Bring coordination needs

Daily Scrum is where you coordinate work across people and specialties.

• Do you need a review today to finish?
• Is there a dependency on another item or teammate?
• Should two people pair to reduce risk or speed up completion?
• Is there a handoff that must happen before lunch to keep flow?

Bring a proposed plan, not just a problem

When you raise an issue, add a suggested next step.

• “I’m blocked by X. After this, I’ll meet with Y for 10 minutes to resolve it.”
• “This item is larger than expected. I propose we split it into A and B so we can finish A today.”

What Changes When Priorities Shift

During a Sprint, new information can change what is most sensible to do next. The Daily Scrum is the primary moment to re-plan the next 24 hours while still protecting the Sprint Goal.

How to adapt without chaos (step-by-step)

1. Re-check the Sprint Goal: Does the new priority affect the goal or just the order of work?
2. Identify the impact: What work becomes less important today? What becomes urgent?
3. Adjust the plan: Reorder tasks, swarm on the new constraint, or pause lower-value work in progress.
4. Reduce WIP: Before starting something new, ask what can be finished or stopped to avoid spreading thin.
5. Escalate appropriately: If the shift threatens the Sprint Goal, coordinate with the Product Owner outside the Daily Scrum to clarify trade-offs.

Examples of healthy priority shifts

• Unexpected defect: The team decides to swarm to fix a critical issue so the Increment remains usable, then resumes planned work.
• Dependency delay: A needed external change is late; the team pulls forward a different item that still supports the Sprint Goal.
• Learning changes the approach: A spike reveals a simpler solution; the team re-plans tasks to finish sooner.

Keeping It for Developers While Still Transparent

The Daily Scrum is for Developers. Others may observe, but the meeting should remain a working session where Developers coordinate and adapt their plan. Transparency comes from visible work and clear outcomes, not from turning the event into a performance.

Practical ways to maintain the right audience and tone

• Speak to each other, not “up”: Use language like “We need…” and “Let’s…” rather than “I reported…”
• Use the board as the shared truth: Keep work status updated so observers can see progress without interrupting.
• Protect the timebox: If observers ask questions, capture them and handle after the Daily Scrum with the relevant people.
• Let Developers facilitate: Any Developer can facilitate; it does not need to be the Scrum Master.

How stakeholders can stay informed without hijacking the Daily Scrum

• Rely on the updated board and the Increment’s current state.
• Use separate syncs for stakeholder questions, release coordination, or scope discussions.
• Ask for a brief follow-up after the Daily Scrum with the right Developers, not the whole team.

Follow-up Conversations: Where Deeper Problem-Solving Belongs

The Daily Scrum often surfaces issues that require more time. The best practice is to keep the Daily Scrum short, then immediately hold targeted follow-ups with only the necessary people.

Common follow-up types (and who should attend)

• Blocker busting: 2–3 people who can remove the obstacle (e.g., developer + ops contact).
• Design/approach discussion: People actively implementing the item (avoid pulling the whole team unless needed).
• Swarming plan: Developers who will pair/mob to finish an item today.
• Clarification with Product Owner: A small group to confirm acceptance expectations or trade-offs when new info appears.

Parking lot technique

When a topic starts to expand, capture it quickly and move on:

Parking lot: Investigate failing integration tests on payment service (Alex + Priya after Daily, 20 min)

This keeps the Daily Scrum focused while ensuring important issues are not ignored.

Common Anti-Patterns (and What to Do Instead)

Anti-pattern: Status reporting to a manager

What it looks like: Each person speaks in turn to a leader, explaining what they did, as if seeking approval.

Why it hurts: It reduces collaboration, hides real problems, and turns the event into a performance rather than planning.

Do this instead: Talk in terms of work and the Sprint Goal. Make commitments to each other for the next 24 hours.

• Replace “Yesterday I…” with “This item needs X to reach Done; I’ll do X, and I need a review from Y.”

Anti-pattern: Problem-solving for the whole meeting

What it looks like: The team dives deep into debugging, design debates, or long explanations while others wait.

Why it hurts: The Daily Scrum loses its planning function; people disengage; the timebox is broken.

Do this instead: Identify the decision needed and schedule a follow-up with the right people.

• In the Daily Scrum: “We have a failing test suite; we’ll investigate after this.”
• After the Daily Scrum: 2–3 people troubleshoot and report back by updating the board and messaging the team.

Anti-pattern: Going around the room with the three questions as a script

What it looks like: Everyone answers “What did I do yesterday, what will I do today, what are my blockers?” even when it doesn’t help planning.

Why it hurts: It can become repetitive and disconnected from finishing work.

Do this instead: Use the three questions only if they help adapt the plan. Prefer board-walk or goal-focused discussion when the team needs stronger alignment.

Anti-pattern: Starting lots of work, finishing little

What it looks like: Many items are “in progress,” few reach Done, and the Daily Scrum becomes a list of partial updates.

Why it hurts: It increases risk and reduces the chance of meeting the Sprint Goal.

Do this instead: Use the Daily Scrum to actively reduce WIP: swarm, pair, and finish the closest-to-done items first.

Anti-pattern: Hiding blockers to look productive

What it looks like: People avoid mentioning risks or delays until it’s too late.

Why it hurts: The team loses the chance to adapt early.

Do this instead: Normalize early escalation: raise blockers within 24 hours, propose a next step, and ask for help explicitly.