Scrum Conductor
Overview
Facilitates AI-enhanced Scrum orchestration with automated ticket management and high-velocity sprint coordination. Synthesizes daily updates from git activity, detects blockers proactively, and maintains backlog integrity across issue trackers.
When to use: Sprint planning, daily standups, backlog grooming, ticket creation, velocity forecasting, sprint retrospectives, estimation, risk management, release planning, cross-tracker synchronization.
When NOT to use: Technical implementation tasks (use specialized coding skills), architecture design, security auditing.
Quick Reference
| Pattern |
Approach |
Key Points |
| Fact-first standups |
Auto-generate from git logs and PRs |
Never ask humans for data in commit history |
| Ticket engineering |
Machine-readable DoD with acceptance criteria |
Binary true/false criteria, implementation pointers |
| Sprint planning |
Capacity calculation with focus factor and velocity |
Budget = avg velocity (last 3 sprints) adjusted for absences |
| Estimation |
Planning Poker with Fibonacci scale, T-shirt sizing for roadmap |
Reference stories anchor the scale, re-calibrate quarterly |
| Capacity forecasting |
Historical cycle time and lead time |
Factor holidays, context debt, and bottlenecks |
| Backlog grooming |
AI clustering and deduplication |
Flag tickets older than 2 sprints for archive |
| Backlog refinement |
1-2 sessions per sprint, Definition of Ready checklist |
Stories must meet DoR before entering sprint planning |
| Blocker detection |
Scan PRs, assignments, and dependencies |
Flag stale PRs, OOO assignees, breaking deps |
| Parking lot |
Move deep-dives out of standups |
Standups focus on status and blockers only |
| Sprint retrospective |
Start/Stop/Continue with action item tracking |
Track retro action completion rate across sprints |
| Risk management |
Dependency mapping, risk register (probability x impact) |
Address risk scores 6+ immediately, monitor 3-5 |
| Release planning |
Multi-sprint roadmap with confidence levels |
Feature flags decouple deployment from release |
| Escalation tiers |
Tier 1 autonomous, Tier 2 clarification, Tier 3 pairing |
Match response to complexity |
| Priority frameworks |
MoSCoW, value vs effort matrix, WSJF |
WSJF favors small high-value items |
Conductor Protocol
- Ceremony Initialization: Identify the current sprint phase (Planning, Daily, Review, Retro)
- Telemetry Sync: Pull recent activity from git commits, PRs, and communication channels
- Fact Synthesis: Generate factual summaries before ceremonies begin
- Verification: Confirm all action items are converted into tracked tickets with clear owners and DoD
Common Mistakes
| Mistake |
Correct Pattern |
| Asking developers for status updates available in commit logs |
Auto-generate fact summaries from PRs and merges before standups |
| Creating tickets without a machine-readable Definition of Done |
Every ticket needs explicit acceptance criteria and technical pointers |
| Guessing sprint velocity without historical data |
Use cycle time, holidays, and context debt to forecast capacity |
| Letting standups run beyond 15 minutes with deep-dive discussions |
Move deep-dives to a parking lot session; standups focus on blockers |
| Allowing the backlog to grow to 200+ items without pruning |
Auto-flag tickets older than 2 sprints for archive or refactor |
| Using AI to replace human conversation |
Use AI to prepare for the conversation, not substitute it |
| Ignoring team sentiment and morale signals |
High velocity with low morale is a leading indicator of burnout |
| No Definition of Done agreed by the team |
Establish a team-wide DoD checklist applied to every story |
| Skipping retrospectives when the sprint "went fine" |
Every sprint has improvement opportunities; consistency builds the habit |
| Sprint planning without capacity calculation |
Calculate capacity: members x available days x focus factor |
| Stories entering sprint without acceptance criteria |
Enforce Definition of Ready before stories enter a sprint |
| Estimating stories individually instead of as a team |
Use Planning Poker so the full team contributes perspective |
| Slicing stories horizontally by layer |
Slice vertically through all layers so each ticket delivers working functionality |
| No dependency mapping between sprint stories |
Map dependencies explicitly and identify the critical path |
| Retro action items with no owner or due date |
Every action item needs an owner, a due date, and follow-up tracking |
Delegation
- Synthesize daily standup summaries from git activity and PRs: Use
Task agent to pull commit logs and generate fact-based updates
- Cluster and deduplicate backlog tickets across issue trackers: Use
Explore agent to scan GitHub Issues, Jira, and Linear for similar or conflicting items
- Plan sprint capacity and risk assessment using historical velocity: Use
Plan agent to model delivery probability and identify at-risk items
References
- Automated daily rituals, fact-checking workflows, blocker detection, sprint planning, retrospectives, and refinement
- Ticket engineering standards, user story templates, estimation techniques, and priority frameworks
- Predictive velocity, sprint metrics, risk management, distributed teams, and release planning
- Multi-agent task handoffs, escalation tiers, AI retrospectives, blocker detection, and human escalation guardrails
1---
2name: scrum-conductor
3description: 'Orchestrates AI-enhanced Scrum ceremonies and sprint coordination. Use when running sprint ceremonies, generating automated daily standups, engineering structured tickets, forecasting sprint capacity, or grooming backlogs. Use for fact-based standups, machine-readable tickets, predictive velocity, and backlog deduplication across GitHub Issues, Jira, and Linear.'
4license: MIT
5metadata:
6 author: oakoss
7 version: '1.1'
8---
9
10# Scrum Conductor
11
12## Overview
13
14Facilitates AI-enhanced Scrum orchestration with automated ticket management and high-velocity sprint coordination. Synthesizes daily updates from git activity, detects blockers proactively, and maintains backlog integrity across issue trackers.
15
16**When to use:** Sprint planning, daily standups, backlog grooming, ticket creation, velocity forecasting, sprint retrospectives, estimation, risk management, release planning, cross-tracker synchronization.
17
18**When NOT to use:** Technical implementation tasks (use specialized coding skills), architecture design, security auditing.
19
20## Quick Reference
21
22| Pattern | Approach | Key Points |
23| -------------------- | --------------------------------------------------------------- | ------------------------------------------------------------ |
24| Fact-first standups | Auto-generate from git logs and PRs | Never ask humans for data in commit history |
25| Ticket engineering | Machine-readable DoD with acceptance criteria | Binary true/false criteria, implementation pointers |
26| Sprint planning | Capacity calculation with focus factor and velocity | Budget = avg velocity (last 3 sprints) adjusted for absences |
27| Estimation | Planning Poker with Fibonacci scale, T-shirt sizing for roadmap | Reference stories anchor the scale, re-calibrate quarterly |
28| Capacity forecasting | Historical cycle time and lead time | Factor holidays, context debt, and bottlenecks |
29| Backlog grooming | AI clustering and deduplication | Flag tickets older than 2 sprints for archive |
30| Backlog refinement | 1-2 sessions per sprint, Definition of Ready checklist | Stories must meet DoR before entering sprint planning |
31| Blocker detection | Scan PRs, assignments, and dependencies | Flag stale PRs, OOO assignees, breaking deps |
32| Parking lot | Move deep-dives out of standups | Standups focus on status and blockers only |
33| Sprint retrospective | Start/Stop/Continue with action item tracking | Track retro action completion rate across sprints |
34| Risk management | Dependency mapping, risk register (probability x impact) | Address risk scores 6+ immediately, monitor 3-5 |
35| Release planning | Multi-sprint roadmap with confidence levels | Feature flags decouple deployment from release |
36| Escalation tiers | Tier 1 autonomous, Tier 2 clarification, Tier 3 pairing | Match response to complexity |
37| Priority frameworks | MoSCoW, value vs effort matrix, WSJF | WSJF favors small high-value items |
38
39## Conductor Protocol
40
411. **Ceremony Initialization**: Identify the current sprint phase (Planning, Daily, Review, Retro)
422. **Telemetry Sync**: Pull recent activity from git commits, PRs, and communication channels
433. **Fact Synthesis**: Generate factual summaries before ceremonies begin
444. **Verification**: Confirm all action items are converted into tracked tickets with clear owners and DoD
45
46## Common Mistakes
47
48| Mistake | Correct Pattern |
49| ----------------------------------------------------------------- | --------------------------------------------------------------------------------- |
50| Asking developers for status updates available in commit logs | Auto-generate fact summaries from PRs and merges before standups |
51| Creating tickets without a machine-readable Definition of Done | Every ticket needs explicit acceptance criteria and technical pointers |
52| Guessing sprint velocity without historical data | Use cycle time, holidays, and context debt to forecast capacity |
53| Letting standups run beyond 15 minutes with deep-dive discussions | Move deep-dives to a parking lot session; standups focus on blockers |
54| Allowing the backlog to grow to 200+ items without pruning | Auto-flag tickets older than 2 sprints for archive or refactor |
55| Using AI to replace human conversation | Use AI to prepare for the conversation, not substitute it |
56| Ignoring team sentiment and morale signals | High velocity with low morale is a leading indicator of burnout |
57| No Definition of Done agreed by the team | Establish a team-wide DoD checklist applied to every story |
58| Skipping retrospectives when the sprint "went fine" | Every sprint has improvement opportunities; consistency builds the habit |
59| Sprint planning without capacity calculation | Calculate capacity: members x available days x focus factor |
60| Stories entering sprint without acceptance criteria | Enforce Definition of Ready before stories enter a sprint |
61| Estimating stories individually instead of as a team | Use Planning Poker so the full team contributes perspective |
62| Slicing stories horizontally by layer | Slice vertically through all layers so each ticket delivers working functionality |
63| No dependency mapping between sprint stories | Map dependencies explicitly and identify the critical path |
64| Retro action items with no owner or due date | Every action item needs an owner, a due date, and follow-up tracking |
65
66## Delegation
67
68- **Synthesize daily standup summaries from git activity and PRs**: Use `Task` agent to pull commit logs and generate fact-based updates
69- **Cluster and deduplicate backlog tickets across issue trackers**: Use `Explore` agent to scan GitHub Issues, Jira, and Linear for similar or conflicting items
70- **Plan sprint capacity and risk assessment using historical velocity**: Use `Plan` agent to model delivery probability and identify at-risk items
71
72## References
73
74- [Automated daily rituals, fact-checking workflows, blocker detection, sprint planning, retrospectives, and refinement](references/daily-rituals.md)
75- [Ticket engineering standards, user story templates, estimation techniques, and priority frameworks](references/ticket-engineering.md)
76- [Predictive velocity, sprint metrics, risk management, distributed teams, and release planning](references/velocity-risk.md)
77- [Multi-agent task handoffs, escalation tiers, AI retrospectives, blocker detection, and human escalation guardrails](references/agile-agents.md)
oakoss