Your team has 15 minutes. Two people are checking Slack. Someone's mic isn't working. And nobody's quite sure what anyone else did yesterday.
Daily standups are supposed to be the heartbeat of Agile execution. Instead, many teams treat them as a checkbox: "I did X, I'm doing Y, I have no blockers." The real work—surfacing obstacles early, aligning on priorities, building shared ownership—gets lost in the noise.
AI prompts won't fix a broken standup format. But they can sharpen focus, pull signal out of noise, and turn 15 minutes into actual coordination. Here are seven prompts, grouped by workflow stage: planning the meeting, running it, reviewing what happened, and ensuring follow-through. Each one is built around a specific role and constraint so your team gets structured output, not generic advice.
Pre-Standup Planning and Goal Alignment
Use this before standups begin to help your team set intentions for the meeting and surface what matters most today.
You are an experienced Scrum Master with 8 years of experience running distributed and co-located teams. Your role is to help teams prepare for daily standups by clarifying what success looks like for today's meeting.
Context: Our team is [team size] people, working in [sprint length]-day sprints. We use [project management tool] to track work. We've struggled with standups feeling unfocused because people don't know what to prioritize in their updates.
Task: Generate 3-4 pre-standup reflection prompts that help team members prepare their updates before the meeting starts, so standup time is spent on blockers and coordination, not recaps.
Constraints: Each prompt should take under 2 minutes to answer. Avoid generic "what are you working on" questions. Instead, focus on blockers, dependencies, and decisions needed today. Optimize for async prep so the synchronous meeting is shorter.
Output format: Numbered list. Each prompt is one sentence, phrased as a question team members can answer in Slack or a shared doc 15 minutes before standup.
Anti-patterns: Do not ask "How are you feeling?" or "What's your energy level?" That's not preparation. Do not create a template that takes longer to fill out than the standup itself.
[Paste your team's last 3 standup notes here so I can tailor these to your actual work patterns.]
Variables to fill in
[team size]— your current team headcount, e.g., 6 people, 12 people[sprint length]— your sprint duration, typically 1 or 2 weeks[project management tool]— the tool you use to track work, e.g., Jira, Azure DevOps, Linear
What to expect
You'll get 3-4 short questions that team members can answer asynchronously before the meeting. These shift the conversation from status updates to actual blockers and dependencies.
When to skip it
If your team is already async-first and uses Slack updates instead of synchronous standups, this prompt adds overhead. Skip it if standups are already under 10 minutes.
Real-Time Blocker Detection During Standup
Run this live during your standup to surface blockers and dependencies your team might gloss over in the moment.
You are a Scrum Master facilitating a daily standup for a [team size]-person [technology stack] team. Your job is to listen for blockers, dependencies, and risks that team members mention but don't explicitly flag as problems.
Context: This team works in [sprint length]-day sprints and uses [project management tool]. We often miss blockers because people describe them casually ("I'm waiting on API docs from the backend team") without calling them out as blockers. We need to surface these quickly so we can escalate or reassign work.
Task: Analyze the standup transcript below and extract every blocker, dependency, and at-risk item, even if it wasn't explicitly labeled as such.
Constraints: Flag only items that actually block progress or require a decision today. Don't over-flag. Prioritize by impact: what stops the most people first. Output must be actionable in under 5 minutes of follow-up discussion.
Output format: Numbered list of blockers. For each, include: blocker name, who it affects, why it matters, and one suggested next step (owner and deadline).
Anti-patterns: Do not flag general backlog items or nice-to-haves. Do not suggest solutions that require meetings outside standup. Do not assume the Scrum Master will handle it.
[Paste your standup transcript here.]
Variables to fill in
[team size]— your team headcount[technology stack]— your primary tech (e.g., React/Node, Java/Spring, Python/Django)[sprint length]— your sprint duration[project management tool]— your tracking tool
What to expect
A prioritized list of actual blockers with owners and next steps. Items that would normally slip through casual conversation get named and assigned in real time.
When to skip it
If your team is already very explicit about blockers and you rarely have hidden dependencies, this adds noise. Use it when you notice blockers emerging in retrospectives that weren't surfaced in standups.
Progress Review and Momentum Assessment
Use this after standup to reflect on what the team accomplished and whether you're on track for the sprint goal.
You are an Agile coach analyzing daily standup data to help a [team size]-person team stay aligned on sprint progress.
Context: Our team is [sprint day] days into a [sprint length]-day sprint. Our sprint goal is: [sprint goal]. We use [project management tool] to track work. We want to know if we're on track, not just if we're busy.
Task: Analyze the standup updates from the past [X] days and assess whether the team is on pace to complete the sprint goal. Identify which areas are at risk and which are ahead.
Constraints: Base your assessment only on what was actually said in standup, not on story point velocity or burndown charts alone. Look for patterns: are the same blockers repeating? Is work flowing across the team or stuck in one person? Highlight momentum shifts, not just current status.
Output format: 1) Overall sprint health (on track / at risk / off track with one-sentence reason). 2) Three strongest areas of progress. 3) Three areas at risk. 4) One recommendation for today's standup follow-up.
Anti-patterns: Do not assume that because people are busy, progress is happening. Do not ignore repeated blockers. Do not make recommendations that require replanning the sprint.
[Paste standup notes from the past [X] days here.]
Variables to fill in
[team size]— your team headcount[sprint day]— the current day of the sprint, e.g., day 3, day 7[sprint length]— your sprint duration[sprint goal]— the one-sentence goal you committed to for this sprint[project management tool]— your tracking tool[X]— number of days of standup notes to analyze, typically 3–5
What to expect
A clear health assessment tied to your actual sprint goal, plus three specific risks and three strong areas. This is different from a burndown report because it's based on what people said, not just metrics.
When to skip it
If you're already running a formal sprint dashboard or mid-sprint check-in, this duplicates that work. Use it if you want a qualitative take on momentum that metrics alone don't show.
Dependency and Communication Mapping
Run this weekly to map which teams or people are blocking each other and where communication is breaking down.
You are a technical program manager helping a [team size]-person team identify communication and dependency patterns that slow down delivery.
Context: Our team works alongside [other teams/departments] and we often discover dependencies in standup that we didn't know about. We use [project management tool] and [communication tool] for async updates. We want to catch dependency misalignment before it becomes a blocker.
Task: Analyze the standup notes from this week and map every external dependency, cross-team handoff, and communication gap.
Constraints: Focus only on dependencies that actually appeared in standup, not hypothetical ones. Prioritize by frequency: if the same team or person is mentioned as a blocker multiple times, flag it first. Suggest one lightweight fix per dependency (not a meeting, not a new process).
Output format: Dependency map. For each dependency: what we need, who has it, how often it's been a blocker this week, and one suggested fix (async doc, shared Slack channel, daily sync, etc.).
Anti-patterns: Do not suggest new meetings. Do not assume the other team knows we're blocked. Do not create a dependency matrix that takes an hour to maintain.
[Paste this week's standup notes here.]
Variables to fill in
[team size]— your team headcount[other teams/departments]— names of teams or systems you depend on, e.g., backend, DevOps, design[project management tool]— your tracking tool[communication tool]— your primary async channel, e.g., Slack, Teams, Discord
What to expect
A clear map of which external dependencies are actually blocking you, how often, and a lightweight fix for each. This often reveals that a 15-minute async doc or a shared Slack channel solves a blocker that people thought required a meeting.
When to skip it
If you have fewer than three external dependencies or your team is fully self-contained, this isn't necessary. Use it when you notice the same external team mentioned as a blocker more than twice a week.
Creative Problem-Solving for Recurring Blockers
Use this when the same blocker shows up multiple times and you need the team to brainstorm solutions together.
You are a Scrum Master facilitating creative problem-solving for a [team size]-person team that keeps hitting the same blocker.
Context: Our team works in [sprint length]-day sprints using [technology stack]. We've identified a recurring blocker: [blocker description]. It's appeared in standup [X] times in the past [Y] days. It affects [who it affects]. We've tried [what you've already tried], and it hasn't fully resolved it.
Task: Generate five unconventional solutions to this blocker that don't require new tools, new hires, or major process changes.
Constraints: Each solution should be testable within one sprint. Avoid solutions that require approvals from outside the team. Prioritize solutions that shift ownership or communication, not just add more work. For each solution, include a one-sentence hypothesis about why it might work.
Output format: Numbered list of five solutions. For each: solution name, how to run it (one sentence), expected outcome, and one risk to watch.
Anti-patterns: Do not suggest "communicate better" or "add a meeting." Do not assume the blocker is permanent. Do not propose solutions that require budget or external approvals.
[Describe the blocker in detail, including when it happens, who notices it first, and what you've already tried.]
Variables to fill in
[team size]— your team headcount[sprint length]— your sprint duration[technology stack]— your primary tech[blocker description]— specific description of the recurring blocker, e.g., "API tests fail during deployment", "design reviews take 3 days"[X]— how many times the blocker appeared, e.g., 4 times[Y]— time period, e.g., 2 weeks[who it affects]— which team members or roles, e.g., frontend devs, QA[what you've already tried]— solutions you've attempted, e.g., "added a checklist", "assigned an owner"
What to expect
Five specific, testable solutions that go beyond the obvious. Most teams find at least one that they can pilot in the next sprint without overhead.
When to skip it
If the blocker is a one-off or external (e.g., waiting for a vendor), this isn't the right tool. Use it only for recurring blockers that the team can influence.
Team Engagement and Participation Analysis
Run this monthly to check whether all team members are engaged in standups and whether anyone is isolated or overloaded.
You are a team health analyst reviewing standup participation patterns for a [team size]-person team.
Context: Our team is [team composition, e.g., "3 backend devs, 2 frontend devs, 1 QA, 1 designer"]. We've noticed that some people talk a lot in standup and others rarely speak. We want to know if that's normal role difference or a sign that someone is stuck, isolated, or overloaded.
Task: Analyze the past [X] days of standup transcripts and assess participation patterns, workload distribution, and early signs of burnout or disengagement.
Constraints: Look for patterns, not one-off observations. Flag if someone hasn't mentioned a blocker in [X] days (they might be stuck and not saying it). Flag if someone is always blocked (they might be overloaded or isolated). Avoid making assumptions about personality or communication style.
Output format: 1) Participation heatmap (who speaks most, least, and what they talk about). 2) Red flags (anyone who looks stuck, overloaded, or isolated). 3) One suggestion for how the Scrum Master can check in.
Anti-patterns: Do not assume quiet people are disengaged. Do not assume busy people are healthy. Do not recommend performance reviews or formal feedback.
[Paste the past [X] days of standup transcripts here.]
Variables to fill in
[team size]— your team headcount[team composition]— brief description of roles, e.g., "4 engineers, 1 designer, 1 QA"[X]— number of days to analyze, typically 5–10
What to expect
A participation map that shows who's talking about what, plus early warning signs of someone being stuck or overloaded. Most teams use this to have a quick 1:1 check-in with someone who looks isolated.
When to skip it
If your team is small (under 5 people) or you already have strong 1:1 cadence, this adds little value. Use it when you suspect participation imbalance but aren't sure.
Action Item Tracking and Accountability
Use this after standup to capture action items, assign owners, and set reminders so commitments don't slip.
You are a Scrum Master capturing and tracking action items from a daily standup to ensure accountability and follow-through.
Context: Our team is [team size] people. We use [project management tool] to track work and [communication tool] for reminders. We've noticed that action items discussed in standup often get forgotten because they're not formally tracked. We want a lightweight system that doesn't add overhead.
Task: Extract all action items from the standup transcript, assign clear owners and deadlines, and suggest a lightweight reminder system.
Constraints: Only flag items that require action outside of regular sprint work (not "finish the story you're working on"). Each action item must have one owner and one deadline. Deadlines should be within the next 24-48 hours unless explicitly stated otherwise. Suggest reminders that don't require new tools.
Output format: Table with columns: action item, owner, deadline, status. Below the table, one suggestion for how to remind people without creating alert fatigue.
Anti-patterns: Do not create action items for things people are already doing. Do not assign action items to people who weren't in standup. Do not set deadlines more than one sprint out.
[Paste the standup transcript here.]
Variables to fill in
[team size]— your team headcount[project management tool]— your tracking tool[communication tool]— your primary async channel
What to expect
A clear action item table with owners and deadlines, plus a one-sentence reminder strategy. Most teams add this table to a shared doc or pinned Slack message so it's visible until items are done.
When to skip it
If your team already uses a formal issue tracker for all action items and reviews it daily, this is redundant. Use it if action items from standup often disappear into the void.
How to Adapt These Prompts for Your Team
These seven prompts are starting points. Your team will get better results if you customize them:
First week: Run each prompt once to see which ones surface real value. You'll probably find that three or four are immediately useful and two or three feel like overhead.
Second week: Drop the ones that didn't help. Refine the ones that did by adjusting the context (team size, tools, sprint length) so the output matches your actual constraints.
Ongoing: Rotate prompts by workflow stage. You don't need all seven every day. Try running Prompt 2 (blocker detection) daily, Prompt 3 (progress review) twice a week, and Prompt 4 (dependency mapping) once a week.
The goal isn't to automate standups or replace human judgment. It's to give your team structured ways to pull signal out of noise so that 15 minutes of talking actually moves the needle.
If you're ready to go deeper on how standups fit into your Scrum practice, check out our guide on whether stakeholders should attend the Daily Scrum. And if you're looking to build this kind of structured thinking across your entire Agile practice, our CSM certification covers the frameworks that make standups (and the rest of Scrum) actually work.
For teams looking to scale these practices across multiple teams, our team coaching and training programs can help you embed this discipline into your organization's DNA.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.