Async standup from Slack + Jira

Automation replaces the synchronous daily standup with an asynchronous digital format. An AI agent analyzes team members' activity in Jira over the last 24 hours, generates a personal update draft for each member, and publishes a summary post to the team's Slack channel.

What the automation does

1. Collects signals from Jira. Retrieves via API all of a member's tickets with changes over the past 24 hours: status transitions, comments, time logs, created and closed tasks.
2. Generates a personal draft. For each member, the bot assembles three blocks: "yesterday" (what was closed), "today" (what is in progress or pulled into the sprint), "blockers" (tickets with the label blocked or stuck at review status). The LLM reformulates the raw changelog into readable text.
3. Sends a reminder to Slack DM. At a set morning time in the member's timezone, the bot sends the draft with "Confirm" and "Edit" buttons.
4. Collects confirmations. The member either confirms the draft with one click or edits the text directly in Slack. Validation takes 2-3 minutes.
5. Publishes the summary post. On schedule, the bot publishes a thread to the team channel: the day's header, member blocks, and a separate list of blockers with owner tags.
6. Triggers follow-up on blockers. All items from the "blockers" block automatically create a subtask in Jira with assignee = team PM and the tag standup-blocker, so that the escalation is not lost.

What the automation does NOT do

• Does not make decisions on blockers. The bot records and tags the PM — escalation resolution remains with a human.
• Does not replace sprint planning, architecture discussions, or retrospectives. This is a daily format, not a weekly or planning one.
• Does not evaluate code quality or team performance. Automation reflects only activity in Jira and does not generate performance review metrics.

The automation is built on a low-code platform (workflow engine or Zapier) and operates via the official REST APIs of Jira and Slack. Data processing and text generation are handled through an LLM AI model. The flow processes the activity of a team of 10-20 people in a few minutes of machine time per day.

Technical flow

1. Cron trigger. The workflow runs on a schedule in the team's morning slot (e.g., 8:45 local time PM).
2. Data collection from Jira. A request to the Jira REST API (/search with JQL: assignee = X AND updated > -24h) returns a list of changed tickets for each team member.
3. Changelog parsing. For each ticket, the workflow extracts the history: status transitions, added comments, scope changes, estimate updates.
4. Draft generation. The collected signals are passed to the LLM with a prompt in three blocks: "yesterday", "today", "blockers". The prompt sets a line limit per block and the team's tone.
5. Sending the draft to Slack DM. Via the Slack Web API (chat.postMessage) the bot sends the draft to the team member with interactive buttons.
6. Receiving confirmation. The Slack Interactivity Endpoint receives a webhook with the click result. The workflow saves the final block text to storage (Airtable, Google Sheets, or PostgreSQL).
7. Publishing the summary post. On cron, all confirmed blocks are collected and published to the team channel #standup-{team}.
8. Creating tasks for blockers. Blockers trigger a Jira issue of type Task with the tag standup-blocker and assignment to the PM.

Components

Implementation phases

1. Week 1 — design and access. Grow2.ai collects the update template from the team (which fields, tone, language), obtains the Jira API token and Slack bot token, and sets up the test environment.
2. Week 2 — workflow assembly.An engineer assembles the workflow in the workflow engine, writes the prompt for the LLM, configures Slack buttons, and tests with 2-3 team members.
3. Week 3 — pilot and calibration. The async standup runs on one team. Grow2.ai collects feedback and adjusts the prompt — the first drafts are often too dry or, conversely, too verbose.
4. Final phase — handover. Follow-up rules for blockers are added, documentation is compiled, and the team's PM receives a confirmation dashboard and skip statistics.

To launch, you need access to Jira and Slack, team agreement on the new format, and 1-3 weeks of engineer work.

Technical requirements

• Jira Cloud or Jira Data Center with REST API access and permissions to create an API token.
• Slack workspace with bot installation permissions. Minimum scopes: chat:write, im:write, commands, users:read.
• A workflow engine account (self-hosted or cloud) or Zapier with a plan supporting webhooks and custom nodes.
• Access to LLM API (Anthropic Claude or equivalent).

Organizational readiness

• Team and department head agreement to give up the synchronous daily. The async format requires discipline: if half the team ignores reminders, automation loses its purpose.
• Agreement on the block format — what counts as a 'blocker', what counts as 'in progress', what counts as 'yesterday'.
• A PM or Team Lead ready to handle blocker escalations in Jira within the working day.

Data

• 2-3 weeks of Jira ticket history for calibrating the LLM prompt (which fields matter, what tone to write in).
• 5-10 examples of 'good' standup updates from the team for few-shot in the prompt.

Timeline

From 1 to 3 weeks from start to production launch on a single team. Scaling to 2-3 teams adds another 1-2 weeks — prompt customization, separate Slack channels, working with multiple time zones.