Daily Standups: The 15-Minute Meeting Most Teams Get Wrong

The daily standup is the most common—and most commonly misused—meeting in software development. When done well, it's a 15-minute sync that surfaces blockers and creates accountability. When done poorly, it's a status update ritual that wastes everyone's time. This guide shows you how to run standups that actually help.

"If your standup could be replaced by a Slack message, it should be replaced by a Slack message."

What is a Daily Standup?

A daily standup (also called a daily scrum or daily huddle) is a short, recurring meeting where team members sync on progress and blockers. The name comes from the practice of standing to keep it short.

The Classic Format

Each person answers three questions:

What did I do yesterday?
What will I do today?
What's blocking me?

The meeting should be 15 minutes or less. Deep dives happen after standup, not during.

Why Standups Fail

Problem	Symptom	Fix
Status reports	People recite task lists to the manager	Focus on blockers, not activities
Too long	Meetings run 30+ minutes	Strict 15-min limit; take deep dives offline
One-way communication	People talk at the team, not with them	Ask "who needs help?" not "what did you do?"
Wrong time	People are distracted, checking in remotely	Find a time that works for the whole team
No follow-through	Blockers mentioned but never resolved	Assign owners to blockers immediately

/// Our Take

The "what did you do yesterday" question is usually waste. If work is tracked in PRs and tickets, yesterday is visible. Standups should focus on the future.

Try replacing the classic three questions with: "What's your focus today?" and "What's in your way?" That's it. If you need to know what happened yesterday, look at the board or the Git log.

Better Standup Formats

The Focus Format

Each person answers two questions:

What's my focus today? (One thing, not a list)
What's blocking me?

This format cuts meeting time in half by eliminating backward-looking updates.

Walk the Board

Instead of person-by-person updates, walk through work items from right to left (closest to done first):

Start with items in "Review" or "Testing"—what's blocking them?
Move to "In Progress"—any help needed?
Check "To Do"—what's starting today?

This focuses on the work, not the people, and naturally surfaces blocked items.

Exception-Based Standup

Default assumption: everyone is on track. The meeting is only for exceptions:

I'm blocked
I finished something major
I need help
Something changed priorities

If no one has exceptions, the standup takes 2 minutes. This works best for experienced teams with visible work tracking.

Identify bottlenecks slowing your team with CodePulse

Async Standups for Distributed Teams

Synchronous standups don't work when teams span multiple time zones. Async alternatives:

Slack Bot Standups

Tools like Geekbot or Standuply post questions in Slack at each person's local morning. Responses are collected in a channel for visibility.

Example Async Standup (Slack)

#standup-engineering
────────────────────────────────
🤖 Standuply Today at 9:00 AM

@sarah
• Focus: Finishing auth API tests
• Blockers: None

@james
• Focus: Code review for payment PR
• Blockers: Waiting on design specs for checkout flow

@priya
• Focus: Investigating prod latency spike
• Blockers: Need access to APM dashboard

────────────────────────────────
💬 Thread: @priya I can grant APM access - DM me

When to Keep Sync Standups

Even distributed teams sometimes benefit from synchronous time. Consider a weekly sync standup (not daily) for:

New team formation (building relationships)
Complex projects with high coordination needs
When blockers are common and need discussion

📊 How to See This in CodePulse

Use CodePulse to make standups data-informed:

PRs awaiting review: Check Dashboard for aging PRs that need attention
Review load: Review Network shows who's overloaded with reviews
Blockers: Set up Alerts for PRs stuck more than 24 hours

Standup Rules That Work

Time Rules

Start on time — Don't wait for latecomers
15 minutes max — Set a timer
Same time daily — Make it a habit

Communication Rules

Talk to the team, not the manager — This isn't a report
One speaker at a time — No side conversations
Deep dives after — Say "let's talk after" and move on

Follow-up Rules

Blockers get owners immediately — Don't wait
Actions tracked — Somewhere visible
Skip if useless — If there's nothing to share, cancel

Standup Anti-Patterns

The Status Report

Everyone talks at the manager about what they did. No one listens to each other. The manager asks follow-up questions, extending the meeting.

The Problem-Solving Session

Someone mentions a technical issue and the whole team starts debugging together. Twenty minutes later, you're still standing in a circle.

The Attendance Check

People say "I'm working on X" just to say something. No blockers, no help needed, no value from the meeting.

The Guilt Trip

People feel pressure to report impressive-sounding work. "Yesterday I just did code review" becomes shameful instead of valuable.

"The best standup is one where someone says 'I'm blocked' and someone else says 'I can help.' If that's not happening, question whether you need the meeting."

Async Code Review for Distributed Teams — Working effectively across time zones
Working Agreements Guide — Setting team norms and expectations
Context Switching Patterns — Protecting focus time around meetings

Conclusion

Daily standups should make your team more effective, not less. If your standup feels like a chore, change it:

Focus on blockers and help—not status reports
Try async formats—especially for distributed teams
Keep it under 15 minutes—or question if you need it daily
Walk the board—focus on work, not people
Skip when unnecessary—not every day needs a meeting

Use tools like CodePulse to surface blockers (aging PRs, review bottlenecks) before standup so the meeting can focus on action, not discovery.