mcpField
S
scrum-conductor

scrum-conductor

github.com/oakossProductivity2085 installsUpdated 10w ago
Repository

About scrum-conductor

Scrum Conductor is a skill for coordinating Scrum ceremonies and delivery planning. It turns git and PR activity into factual updates and supports ticket quality, sprint capacity, backlog refinement, blocker detection, and risk tracking.

Key features

  1. 01Summarize git and PR activity for standups
  2. 02Create tickets with acceptance criteria
  3. 03Calculate sprint capacity from velocity and availability
  4. 04Cluster and prune backlog items
  5. 05Detect blockers across PRs and dependencies
  6. 06Track risks and retrospective actions

Use cases

  1. 01Prepare fact-based daily standup updates
  2. 02Plan sprint scope using team capacity
  3. 03Refine and deduplicate issue backlogs
  4. 04Identify delivery blockers and track follow-up actions

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/oakoss/agent-skills --skill scrum-conductor

After installing, type/scrum-conductorin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
agile-agents.md
daily-rituals.md
ticket-engineering.md
velocity-risk.md

Details

From the project README

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

PatternApproachKey Points
Fact-first standupsAuto-generate from git logs and PRsNever ask humans for data in commit history
Ticket engineeringMachine-readable DoD with acceptance criteriaBinary true/false criteria, implementation pointers
Sprint planningCapacity calculation with focus factor and velocityBudget = avg velocity (last 3 sprints) adjusted for absences
EstimationPlanning Poker with Fibonacci scale, T-shirt sizing for roadmapReference stories anchor the scale, re-calibrate quarterly
Capacity forecastingHistorical cycle time and lead timeFactor holidays, context debt, and bottlenecks
Backlog groomingAI clustering and deduplicationFlag tickets older than 2 sprints for archive
Backlog refinement1-2 sessions per sprint, Definition of Ready checklistStories must meet DoR before entering sprint planning
Blocker detectionScan PRs, assignments, and dependenciesFlag stale PRs, OOO assignees, breaking deps
Parking lotMove deep-dives out of standupsStandups focus on status and blockers only
Sprint retrospectiveStart/Stop/Continue with action item trackingTrack retro action completion rate across sprints
Risk managementDependency mapping, risk register (probability x impact)Address risk scores 6+ immediately, monitor 3-5
Release planningMulti-sprint roadmap with confidence levelsFeature flags decouple deployment from release
Escalation tiersTier 1 autonomous, Tier 2 clarification, Tier 3 pairingMatch response to complexity
Priority frameworksMoSCoW, value vs effort matrix, WSJFWSJF favors small high-value items

Conductor Protocol

  1. Ceremony Initialization: Identify the current sprint phase (Planning, Daily, Review, Retro)
  2. Telemetry Sync: Pull recent activity from git commits, PRs, and communication channels
  3. Fact Synthesis: Generate factual summaries before ceremonies begin
  4. Verification: Confirm all action items are converted into tracked tickets with clear owners and DoD

Common Mistakes

MistakeCorrect Pattern
Asking developers for status updates available in commit logsAuto-generate fact summaries from PRs and merges before standups
Creating tickets without a machine-readable Definition of DoneEvery ticket needs explicit acceptance criteria and technical pointers
Guessing sprint velocity without historical dataUse cycle time, holidays, and context debt to forecast capacity
Letting standups run beyond 15 minutes with deep-dive discussionsMove deep-dives to a parking lot session; standups focus on blockers
Allowing the backlog to grow to 200+ items without pruningAuto-flag tickets older than 2 sprints for archive or refactor
Using AI to replace human conversationUse AI to prepare for the conversation, not substitute it
Ignoring team sentiment and morale signalsHigh velocity with low morale is a leading indicator of burnout
No Definition of Done agreed by the teamEstablish 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 calculationCalculate capacity: members x available days x focus factor
Stories entering sprint without acceptance criteriaEnforce Definition of Ready before stories enter a sprint
Estimating stories individually instead of as a teamUse Planning Poker so the full team contributes perspective
Slicing stories horizontally by layerSlice vertically through all layers so each ticket delivers working functionality
No dependency mapping between sprint storiesMap dependencies explicitly and identify the critical path
Retro action items with no owner or due dateEvery 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

Comments

Markdown supported