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 past 24 hours, generates a personal update draft for each one, and publishes a summary post to the team's Slack channel.

What automation does

1. Collects signals from Jira. Pulls 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 is closed), "today" (what is in progress or taken into the sprint), "blockers" (tickets with the blocked label or stuck at review status). An 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 a summary post. On schedule the bot publishes a thread to the team channel: the day's header, members' 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 the escalation is not lost.

What automation does NOT do

• Does not make decisions on blockers. The bot records and tags the PM — handling escalations remains a human responsibility.
• Does not replace sprint planning, architectural discussions, or retrospectives. This is a daily format, not weekly or planning.
• 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 through the official REST APIs of Jira and Slack. Data processing and text generation are handled via an LLM AI model. The flow processes team activity for 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 PM time).
2. Data collection from Jira. A request to the Jira REST API (/search with JQL: assignee = X AND updated > -24h) returns a list of updated 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. Via 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 stages

1. Week 1 — design and access. Grow2.ai collects the update template from the team (which fields, tone, language), receives the Jira API token and Slack bot token, and sets up the test environment.
2. Week 2 — workflow build.The 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 is launched with 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 prepared, and the team 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 an LLM API (Anthropic Claude or equivalent).

Organizational readiness

• Team and department head agreement to drop 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 prepared 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 use).
• 5-10 examples of "good" standup updates from the team for few-shot use in the prompt.

Timeline

From 1 to 3 weeks from start to production launch for one team. Scaling to 2-3 teams adds another 1-2 weeks — prompt customization, separate Slack channels, handling multiple time zones.