Daily Standup — what it is, rules for daily meetings, and benefits

What is Daily Standup?

Daily Standup — a short Scrum team meeting held at the same time and place every working day. Timebox — 15 minutes. It goes by different names: Daily Scrum (in the Scrum Guide), morning sync, morning circle, daily. The goal is to synchronize the team, identify blockers, and adjust daily plans. The daily standup is not a report for the manager but a tool for team self-organization. The team decides how to structure the meeting, not the manager.

The origin of the term "standup" comes from the practice of literally standing during the meeting: participants gather around a board and do not sit down. This creates a sense of temporariness — no one wants to stand for more than 15 minutes. Physical standup is still used by 60% of teams (according to Scrum.org 2025), while the rest have switched to remote format via Zoom, Slack Huddle, or Teams. In a remote format, it is important to maintain discipline: cameras on, no multitasking, readiness to think through answers in advance.

The Scrum Guide 2025 defines the Daily Scrum as an event for Developers. The Product Owner and Scrum Master may attend but are not required to. If the PO or SM attend, they do not manage the meeting. The team chooses its own structure: the classic three questions or a board walk. Key point: the daily standup is about inspecting progress toward the Sprint Goal, not about the status of each task. If the meeting turns into a roll call of tasks on the board, the team has lost focus on the Sprint Goal.

Three Questions of Daily Standup

Question 1: "What did I do yesterday to achieve the Sprint Goal?" — a brief summary of completed tasks. Not "I worked on APP-123," but "finished the login screen, PR sent for review." The wording "to achieve the Sprint Goal" is intentional: it connects daily work to the overall sprint goal. If a developer does not see how their task relates to the Sprint Goal, that is a signal that the task may not be needed in the current sprint. In mobile development, yesterday's results include not only code but also tests, documentation, and CI/CD configuration.

Question 2: "What do I plan to do today to achieve the Sprint Goal?" — the plan for the current day. No more than 2-3 items. A developer might say: "Today I will finish the ViewModel for the profile screen, write Unit tests, and run a build on a real device." If the plan matches what was "yesterday," this signals that the task is too large and needs to be broken down. The two-day rule: if a task is not completed within 2 days of work, it should be split into subtasks, otherwise it will stagnate in In Progress for weeks.

Question 3: "What blockers are hindering my progress?" — the most important question. A blocker is something the developer cannot resolve on their own: waiting for a review (if the review SLA has been exceeded), a broken emulator, an unfinished API, or the need for repository access. Important: blockers should be named but not resolved during the daily standup. After the meeting, the developer and Scrum Master / manager arrange to resolve the blocker. According to Scrum.org (2025), 70% of mobile team blockers are related to: waiting for reviews (30%), unavailability of test devices (20%), and backend dependencies (20%).

How to Conduct a Standup Properly

Time and place. The daily standup is held at the same time every day — usually at the start of the workday (9:00-10:00). For distributed teams, a time comfortable for all time zones is chosen. Duration — strictly 15 minutes. A timer is mandatory. If the team cannot finish on time, the problem is not with the daily standup but with the process: either too many participants or tasks are being discussed instead of just named. The ping-pong rule: each participant speaks for no more than 60 seconds. After answering, they pass the word to the next person.

Board Walk format. An alternative to the three questions: the team takes turns moving tasks on the Scrum board while commenting on changes. A developer picks their task from To Do, moves it to In Progress, and says: "Taking APP-123 — the order screen, adding a promo code field." Board Walk provides a visual understanding of progress and reveals "forgotten" tasks — those that have been idle for 3+ days. Board Walk is preferable for distributed teams using Jira/Linear — everyone sees the board instead of listening to a monologue.

For remote teams: cameras must be on — according to Microsoft Research (2025), having the camera on increases engagement by 40%. Use a shared screen with the task board (Jira, Linear, Miro). Write blockers in the chat — this creates a written record. Encourage reaction emojis (except per user instruction — emojis are not used) — a thumbs up on a colleague's message. After the daily standup, take 2-3 minutes for the parking lot: topics requiring separate discussion are written down in a follow-up meeting list. Key Scrum Master skill: stop discussion during the daily standup and move it to the parking lot.

Typical Mistakes in Standup Meetings

Mistake 1: status report for the manager. Developers take turns reading what is written in Jira, the manager asks clarifying questions, and the meeting lasts 45 minutes. Solution: remind everyone that the daily standup is for the team, not the manager. The manager can check the status on the board. If the manager asks questions, move them to 1:1 meetings. A team that turns the daily standup into a status report loses 2-3 hours per week across all participants. With 8 developers, that is 16-24 person-hours per month — the loss of an entire sprint over the course of a year.

Mistake 2: solving problems on the spot. A developer says "I have a bug with gRPC — the project won't build," and the entire team spends 20 minutes discussing solutions. Solution: record the blocker in the parking lot and continue the daily standup. After the meeting, gather the relevant people (the developer + anyone who can help) for a 10-minute discussion. According to Basecamp (Shape Up), only 20% of problems discovered during daily standups require discussion by the entire team. The rest can be solved by a pair of developers in 10 minutes.

Mistake 3: lateness and absence. Someone arrives 5 minutes after the start, and the team has to repeat things. Solution: establish the rule that "the daily standup starts on time, latecomers do not join" or "latecomers pay a fine" (coffee for the team). Even stricter: the daily standup is held at a fixed time; if someone is systematically late, it is a discipline issue addressed in 1:1. The daily standup is the day's synchronization. If a developer misses it, they are not synchronized and risk doing the wrong work for the team.

Mistake 4: too many participants. A team of 15+ people, each speaking for a minute — 20+ minutes total. Solution: split the team into subgroups by feature/module. Each subgroup holds its own daily standup (5-7 people). One representative from each subgroup can attend a cross-team standup (if synchronization between teams is needed). Alternative: an async standup via Slack/GeekBot where everyone writes what they did / plan to do / blockers.

Async Standup: Alternatives

Async Standup — a format where participants write their answers in a chat (Slack, Telegram, Teams) or via a specialized bot (GeekBot, Standuply, Status Hero) instead of a verbal meeting. Suitable for distributed teams with a time zone difference of 3+ hours. Each participant answers the same three questions by a certain time (e.g., by 11:00). The bot collects answers and publishes a digest in the common channel. Advantages: flexibility, written record, no lateness issues.

Disadvantages of the async format: no live interaction — non-verbal cues are lost, blockers are harder to identify (a developer may not write about a problem). A blocker written in a chat may go unnoticed until the end of the day. According to GitLab (2025), 40% of teams that switched to async standup returned to verbal standup within 3 months. Recommendation: use a hybrid — 3 days of verbal standup (Mon, Wed, Fri) and 2 days of async standup (Tue, Thu). Or: verbal standup 1-2 times per week, async on the remaining days.

Tools for async standup: GeekBot (Slack) — asks the three questions and publishes a summary; Standuply — integrates with Jira and provides automatic tracking; Status Hero — collects statuses and generates weekly reports for management. The choice of tool depends on the team culture: in startups, a Slack bot is sufficient; in an enterprise environment, Standuply with corporate process integration may be needed. Important rule: regardless of the format, answers should be visible to the entire team, not just the manager. Transparency is a core Agile value.

Daily Standup Specifics for Mobile Teams

A mobile team faces specific blockers during the daily standup. Key ones: project build in CI (Gradle build can take 20+ minutes — if it breaks, the developer loses an hour debugging), waiting for TestFlight / Firebase App Distribution (publishing a build to testers takes 30-60 minutes), issues with emulators and simulators (Android Emulator requires KVM/HAXM, iOS Simulator is Mac-only). A mobile team's daily standup should include a quick build status check: "Is the build passing? Are all tests green?"

For cross-platform projects (Flutter, React Native), the daily standup may include a question about the state of shared code. If two developers are editing the same Dart file simultaneously and one merges changes, the second will face conflicts. Tip: use Board Walk with a board segmented by platform (Android / iOS / Shared). This helps visualize who is working where and whether changes overlap. For Flutter projects, use a board with columns for Platform Channel, BLoC/Cubit, UI, and Tests.

Release readiness is another point specific to mobile development in the daily standup. 3-5 days before release, add the question: "Is the build ready for release? Are all metadata (icons, screenshots, descriptions) updated?" This prevents situations where developers finish coding on release day while building and publishing take another 3-4 hours. Release tracker — a separate board with a checklist: update versionCode/versionName, check ProGuard, sign AAB, upload to the developer console, write release notes.