Use case
Scrum and project management agents
Scrum masters and EMs spend hours on status synthesis every week. A Dezifi scrum agent reads Jira and GitHub and writes the standup notes, sprint summary and release notes for them.
What you'll learn
- How to design an agent that aggregates across project tools
- Which signals indicate a real blocker
- How to keep standup notes useful, not noisy
- How to run this across multiple teams without manual setup
The agent design
Project agents are summarization-heavy. Quality depends on grounded retrieval, not raw model size.
- 1
LLM choice
Claude Sonnet or GPT-4o for synthesis quality. Token cost is low per run because input is bounded by sprint scope. - 2
Tools
Jira (sprint board, issues, comments, transitions), GitHub (linked PRs and commits), Linear if applicable, Slack (deliver standup notes and sprint summaries), Confluence for sprint reports. - 3
Guardrails
Read-only by default. Allow agent to add Jira labels but not change status, assignee or priority. Surface blockers — never resolve them autonomously. - 4
Workflow shape
Daily cron at 8:30am: walk the active sprint, group tickets by assignee, detect status changes since yesterday, identify stale tickets, post to Slack. End-of-sprint: full sprint review summary to Confluence.
Tools to connect
- Jira — primary source of truth for sprint state.
- GitHub — link PRs to tickets for delivery signal.
- Slack — deliver standup notes to the team channel.
- Confluence — post sprint summaries and release notes.
How to set this up in Dezifi
- 1
Connect Jira and GitHub
Integrations → Jira and GitHub → OAuth. Scope Jira to the projects you want to track. - 2
Create the agent
New Agent → "Scrum Companion". Attach Jira, GitHub, Slack, Confluence. Use Claude Sonnet. - 3
Build the daily standup workflow
Trigger: daily 8:30am cron. Steps: fetch sprint board → diff against yesterday's snapshot → group by assignee → agent drafts "What changed, what's blocked, what's next" → post to Slack. - 4
Build the sprint-summary workflow
Trigger: Jira sprint_closed event. Steps: aggregate completed, carried-over and dropped tickets → agent writes a sprint summary → publish to Confluence. - 5
Tune blocker detection
Blockers are usually tickets with the "blocked" label or no status change for 3+ days while in-progress. Encode this as a rule, not as agent intuition.
Frequently asked questions
- Does this replace standup meetings?
- No. It replaces the status-readout portion. Teams keep the meeting for discussion, problem-solving and team feel.
- How does it know what counts as a blocker?
- You configure the signals — typically a "blocked" label, a status of "Waiting", or no movement for N days. The agent applies your rules consistently.
- Can we run this across multiple teams?
- Yes. Each team gets its own workflow with its own Jira board scope. Use a single agent, or fork per team if their conventions differ.
- What about release notes?
- Run a separate workflow on release-cut. The agent pulls merged PRs and resolved Jira tickets in the release window and drafts customer-facing notes.