Daily Standup
Purpose: Keep the team aligned on daily progress and surface blockers early
How to run this meeting
The standup works best when it's treated as a coordination ceremony, not a status report to management. Keep everyone standing — physically or metaphorically — to discourage long-winded updates. The goal is to identify where the team needs to swarm, not to go around the room and recite what everyone did.
Structure the meeting around the board, not the people. Walk the tickets in progress column by column, right to left (closest to done first). This naturally surfaces items that are stuck or at risk before you talk about what's just starting. Anyone who has nothing to say about a ticket should feel comfortable saying so in five seconds.
Timebox ruthlessly. If a blocker or cross-team dependency comes up that needs more than 30 seconds, say "let's take that offline" and add it to the parking lot. The standup is for surfacing issues, not solving them. Assign a specific owner to every parked item before you close.
Before the meeting
- Update your tickets in the issue tracker before the meeting starts
- Review the board so you know what's in progress and what's blocked
- Note any blockers or help needed that arose since yesterday
- If you're facilitating, open the board and be ready to drive
Meeting Details
- Date:
- Facilitator:
- Attendees:
- Duration: 15 minutes
What I worked on yesterday
Quick summary of completed or progressed work. One to two sentences per person — link to tickets, not prose.
- @maya closed out #1142 (auth token refresh) and reviewed #1138
- @dev finished the first pass on the dashboard query optimization
- @priya was OOO — async update in Slack
What I'm working on today
Each person's top one or two items for the day. Flag if priorities have shifted from what was planned.
- @maya: picking up #1149 (rate limiting middleware), then unblocking #1138 review
- @dev: finishing query optimization, pairing with @priya on the migration script this afternoon
- @priya: back today, starting on #1153 (webhook retry logic)
Blockers
Hard stops that prevent work from moving forward. Every blocker needs an owner and a plan.
- #1147 is blocked on design approval — @maya pinged @sarah yesterday, no response yet. Escalating today.
- Staging environment is flaky; deploys failing intermittently. @dev owns a fix by EOD.
Help needed
Asks that don't rise to the level of blockers but where input or a second set of eyes would help.
- @priya would like a quick code review of her webhook PR before EOD — any takers?
- @maya looking for someone with RDS experience to sanity-check her connection pool config
Notes / Decisions
Anything decided or worth recording from today's standup.
- Team agreed to hold off on merging #1150 until staging is stable
- Sprint demo is Friday at 2pm — everyone should have their feature branch merged by Thursday noon
Action Items
| Owner | Action | Due Date | Status |
|---|---|---|---|
| @maya | Follow up with @sarah on design approval for #1147 | Today | Open |
| @dev | Investigate and fix flaky staging deploys | Today EOD | Open |
| @priya | Post webhook PR for review in #eng-reviews | Today | Open |
Follow-up
Blockers and parking lot items should be resolved synchronously or tracked in the issue tracker. The facilitator should post a brief summary in the team Slack channel for anyone who missed the meeting. If the same blocker appears two days in a row, escalate — don't wait for it to resolve itself.
Skip the template
Let Stoa capture it automatically.
In Stoa, the AI agent listens to your daily standup and captures decisions, drafts artifacts, and tracks open questions in real time — no note-taking required.
Create your first Space — free