Scrum Conductor

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

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

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

Agile with AI Agents

The Agent as a Team Member

AI agents participate in the sprint as ephemeral team members with defined responsibilities and accountability.

Task Handoff Protocols

When a human or orchestrator delegates a ticket to an agent:

• Input: The ticket with full context and acceptance criteria
• Output: A pull request or a blocker report explaining what prevented completion
• Timeout: If the agent cannot make progress within its allocated time, it must report status and hand back

Supervisor Checkpoints

Every agent-completed task must be validated by a supervisor (either a human or a high-level auditor agent):

• No agent-written code goes to the main branch without an independent review
• The supervisor checks against the ticket's acceptance criteria
• Architectural decisions made by agents require human sign-off

Escalation Tiers

• Tier 1: Agent solves the task autonomously and submits a PR
• Tier 2: Agent asks for clarification on a specific technical point before proceeding
• Tier 3: Agent identifies a fundamental logic gap or ambiguous requirement and requests a human pairing session

The goal is to maximize Tier 1 completions while ensuring Tier 2 and Tier 3 escalations happen promptly rather than being delayed.

AI-Driven Retrospectives

Use AI to analyze the sprint and suggest improvements:

• "40% of time was spent on CSS bugs. Consider activating a UI-focused specialist for the next sprint."
• "The auth module is a bottleneck with 3 developers blocked. Suggest refactoring into a separate package."
• "Review turnaround time increased 50% this sprint. Consider rotating review duties."

Agent-Assisted Sprint Planning

Velocity Analysis

Agents analyze past sprint data to generate planning recommendations:

### Sprint 15 Planning — Agent Analysis

**Historical Velocity (last 5 sprints):**
Sprint 10: 28 pts | Sprint 11: 34 pts | Sprint 12: 31 pts | Sprint 13: 36 pts | Sprint 14: 32 pts

**Recommended capacity**: 32 points (rolling average, adjusted for 1 developer on PTO)

**Carry-over from Sprint 14**: PROJ-198 (5 pts, 60% complete)

**Risky stories in the proposed backlog:**

- PROJ-210 (8 pts): Depends on external API not yet approved — suggest deferring or adding mock fallback
- PROJ-215 (5 pts): Touches the auth module which had 3 rework cycles last sprint — suggest pairing

Sprint Capacity Suggestions

The agent factors in data humans often forget:

• Planned absences: Cross-reference PTO calendars, holidays, and conference schedules
• On-call rotation: Whoever is on-call gets 30-50% less sprint capacity
• Carry-over work: Unfinished stories from the previous sprint consume capacity
• Meeting load: Sprints with release planning or quarterly reviews lose 0.5-1 day per person
• Historical focus factor: Calculate from actual completed vs committed points over last 3 sprints

Identifying Risky Stories

The agent flags stories that are statistically likely to slip:

Automated Blocker Detection

Stale PR Detection

Flag pull requests that have been open too long without progress:

Failing CI Pipelines

Monitor CI health across the team:

• Flaky test detection: If the same test fails intermittently across 3+ PRs in a sprint, auto-create a tech debt ticket
• Build time trending: Alert when average CI time increases by 20%+ over a sprint
• Main branch health: If main is red for more than 2 hours, escalate to the team immediately

Unreviewed and Stale Stories

Scan the sprint board daily for stories that are stuck:

• In Progress >3 days with no PR opened: Check if the developer is blocked or needs help
• In Review >2 days with no reviewer comments: Reassign or escalate
• Blocked >1 day with no update on the blocker: Ping the blocking team or dependency owner

AI Retrospective Analysis

Sentiment Analysis of Retro Feedback

Analyze the tone and content of retrospective submissions:

### Sprint 14 Retro — Sentiment Summary

**Overall sentiment**: Neutral-positive (62% positive, 28% neutral, 10% negative)

**Positive themes**: Team collaboration, deployment process improvements
**Negative themes**: Meeting overload, unclear requirements on 2 stories
**Shift from last sprint**: Negative sentiment decreased 15% (meetings were reduced)

Recurring Theme Detection

Track themes across multiple retrospectives to identify persistent issues:

### Recurring Themes (Last 5 Sprints)

| Theme                      | Sprints Mentioned | Trend                           | Status                      |
| -------------------------- | ----------------- | ------------------------------- | --------------------------- |
| "Too many meetings"        | 4 of 5            | Improving (action taken in S13) | Monitor                     |
| "Unclear requirements"     | 3 of 5            | Stable                          | Needs escalation to product |
| "Slow CI pipeline"         | 2 of 5            | New                             | Action item created         |
| "Great team collaboration" | 5 of 5            | Stable                          | Keep doing                  |

Themes appearing in 3+ consecutive sprints without resolution should be escalated from the team level to management.

Action Item Follow-Up Tracking

Every retro action item is tracked through completion:

### Action Item Status — Sprint 15 Retro Opening

| Action Item                   | Assigned      | Sprint Created | Status          |
| ----------------------------- | ------------- | -------------- | --------------- |
| Reduce standup to 10 min      | Scrum Master  | S13            | Completed (S14) |
| Add linting to CI pipeline    | DevOps lead   | S13            | Completed (S14) |
| Clarify DoR with product team | Product Owner | S14            | In Progress     |
| Investigate CI build times    | DevOps lead   | S14            | Not Started     |

Completion rate of retro action items is itself a metric. Below 50% completion indicates the team is identifying problems but not solving them.

Guardrails: When Agents Escalate to Humans

Mandatory Human Escalation

Agents must hand off to humans for decisions that require organizational context, empathy, or authority:

Soft Escalation Signals

Agents should flag (not escalate) when they detect these patterns:

• Velocity dropping for 3+ consecutive sprints: Could indicate burnout, tech debt, or team issues
• Single developer blocking multiple stories: Knowledge silo risk
• Repeated scope changes mid-sprint: Product alignment issue
• Retro action items not being completed: Process improvement fatigue

Flag these in the sprint summary for human review. Do not attempt to resolve organizational issues autonomously.

Agent Autonomy Boundaries

Fully Autonomous (Tier 1):
  - Generate standup summaries from git data
  - Flag stale PRs and blockers
  - Calculate velocity and capacity metrics
  - Detect duplicate backlog items
  - Format sprint reports and dashboards

Assisted (Tier 2 — agent proposes, human approves):
  - Sprint capacity recommendations
  - Story priority suggestions
  - Risk register updates
  - Retro theme analysis and action item proposals

Human Only (Tier 3 — agent provides data, human decides):
  - Sprint goal definition
  - Scope negotiation with stakeholders
  - Team performance discussions
  - Architectural direction
  - Process changes (ceremony format, cadence, tools)

Daily Rituals

The AI Pre-Standup

The first step in any daily ceremony is automated fact gathering. The orchestrator scans:

• Git Logs: What was merged? What is still in PR? What PRs have been open for more than 3 days without review?
• CI/CD: Are there any broken builds on the main branch? Any flaky tests trending upward?
• Tickets: Which tickets changed status? Which are blocked or stale?

Status Synthesis

Instead of reading raw lists, the AI generates a contextual summary that highlights what matters:

### Daily Update: Sprint Day 7

**Fact Summary:**

- **Done**: 4 PRs merged (auth-refactor, search-index, billing-fix, docs-update)
- **In Progress**: payment-webhooks (80% complete, blocked by staging env config)
- **Blockers**: Rate limit hit on external API (escalated to Ops team)

**Strategic Focus:**
Velocity is on track. The auth module shows increasing "failed quality" labels.
Consider a pairing session to address test coverage gaps.

Blocker Detection

AI identifies hidden blockers that humans often miss:

• A PR that has been open for 3+ days with no review assigned
• A ticket assigned to someone who is currently out of office
• A dependency on a library that released a breaking change
• A CI pipeline that has been failing intermittently on the same test

The Parking Lot Workflow

The standup is for status updates and blockers. Deep technical discussions move to the parking lot:

• The AI identifies keywords during the standup (refactor, architecture decision, design review) and adds them to a shared document for a post-standup session
• Each parking lot item gets a time-box estimate and an owner
• Items not addressed within 48 hours are converted to tracked tickets

Sprint Planning Mechanics

Capacity Calculation

Sprint capacity determines how much work the team can realistically commit to:

Sprint Capacity = Team Members × Available Days × Focus Factor

Example:
  5 developers × 9 working days × 0.7 focus factor = 31.5 available dev-days

Focus factor adjustments:

Subtract planned absences (PTO, holidays, conferences) per person before applying the focus factor.

Story Point Budgeting

Once capacity is known, map it to story points using the team's historical velocity:

Sprint Budget = Average Velocity (last 3 sprints) adjusted for capacity changes

Example:
  Last 3 sprints: 34, 38, 32 points → Average = 34.7
  This sprint: 1 developer on PTO for 3 days → Reduce by ~12%
  Adjusted budget: ~30 points

Pull stories from the top of the prioritized backlog until the budget is filled. Leave a 10-15% buffer for unplanned work and bug fixes.

Sprint Goal Definition

Every sprint needs a single, clear goal that answers "what are we trying to achieve?":

• Good: "Users can complete the checkout flow end-to-end with Stripe integration"
• Bad: "Work on payments stuff"
• Bad: "Complete PROJ-101, PROJ-102, PROJ-103, PROJ-104"

The sprint goal is NOT a list of tickets. It is the outcome that the collection of tickets delivers. If a story does not contribute to the sprint goal, question whether it belongs in this sprint.

Retrospective Framework

Start / Stop / Continue

The simplest and most effective retrospective format:

### Sprint 14 Retrospective

**Start:**

- Pair programming on complex tickets (auth module had 3 rework cycles)
- Writing ADRs for architectural decisions before implementation

**Stop:**

- Skipping code review for "small" PRs (2 production bugs from unreviewed changes)
- Scheduling meetings during core coding hours (10am-2pm)

**Continue:**

- Daily async standups in Slack (95% participation rate)
- Feature flagging all new features before release

Action Item Tracking

Retrospective insights are worthless without follow-through:

• Every action item gets an owner and a due date (default: mid-sprint)
• Action items are tracked as tickets in the same backlog, tagged retro-action
• Review previous sprint's action items at the start of each retrospective
• If an action item carries over for 2+ sprints, either escalate or acknowledge it as accepted debt

Velocity Trending Analysis

Use retrospectives to discuss velocity trends, not just the current sprint:

• Increasing velocity: Is the team genuinely faster, or are estimates inflating?
• Decreasing velocity: Is technical debt accumulating? Are there new team members ramping up?
• Erratic velocity: Are scope changes mid-sprint causing churn?

Compare committed vs completed points over the last 5 sprints to identify patterns.

Backlog Refinement

When to Refine

Schedule 1-2 refinement sessions per sprint, each 30-60 minutes:

• Mid-sprint session: Refine stories for the next sprint
• Late-sprint session: Final grooming before sprint planning

Refinement is NOT planning. The goal is to make stories "ready" so planning is efficient.

What to Refine

Each story in refinement should be evaluated for:

• Acceptance criteria: Are they binary (yes/no verifiable)?
• Estimation: Does the team agree on the size?
• Dependencies: Are external dependencies identified and tracked?
• Testability: Can QA write test cases from the acceptance criteria alone?
• Implementation pointers: Are relevant files, APIs, or interfaces referenced?

Definition of Ready Checklist

A story is ready for sprint planning when all criteria are met:

**Definition of Ready:**

- [ ] User story follows "As a [role], I want [feature], so that [benefit]" format
- [ ] Acceptance criteria are binary and independently verifiable
- [ ] Story is estimated by the team (not just one person)
- [ ] Dependencies are identified and either resolved or tracked
- [ ] UI mockups or wireframes attached (if applicable)
- [ ] Technical constraints documented (performance budgets, API limits)
- [ ] Story fits within a single sprint (if not, split it)

Stories that fail the Definition of Ready checklist go back to the product owner for clarification before entering a sprint.

Demo and Sprint Review

Stakeholder-Friendly Format

Sprint reviews are for stakeholders, not developers. Structure the demo around outcomes:

### Sprint 14 Review

**Sprint Goal:** Users can complete checkout with Stripe integration

**Completed (Demo Order):**

1. [DEMO] Checkout flow walkthrough (live demo on staging)
2. [DEMO] Payment confirmation email with receipt
3. [SLIDE] Stripe webhook reliability metrics (99.8% delivery rate)
4. [SKIP] Internal refactor of billing module (no visible change)

**Not Completed:**

- Subscription management (carried to Sprint 15, blocked by Stripe API approval)

**Key Metrics:**

- 32 of 34 story points completed (94%)
- 0 production incidents
- 2 tech debt items addressed

Demo items that have visible user impact first. Internal refactors and infrastructure work get a brief mention, not a walkthrough.

Feedback Capture

Capture stakeholder feedback in a structured format during the review:

Decision Log

Track decisions made during sprint reviews so they are not lost:

**Decisions — Sprint 14 Review:**

1. Apple Pay integration moves to Q2 roadmap (not Sprint 15)
2. Mobile performance budget set to <2s load time for checkout
3. Subscription management is the Sprint 15 goal

Decisions made in meetings without a written record have a habit of being revisited. Write them down, assign owners, and reference them when the topic resurfaces.

Ticket Engineering

Writing for Two Audiences

Tickets are read by humans and AI agents. They must be precise enough for both.

The Context Section (Why)

Explain the business or technical reason for the task:

• Good: "Needed to comply with new billing meter requirements from the payment provider"
• Bad: "Update payment code"

Implementation Pointers (Starting Point)

For AI agents, provide a clear starting point:

• Relevant file path (e.g., src/lib/billing.ts)
• Interface or type name to reference
• Link to external documentation if applicable

Acceptance Criteria

Must be binary (true/false). Each criterion is independently verifiable:

## [FEAT] Implement Usage Dashboard

**Context**: Users need to see their current billing usage.

**Implementation**: Start at `src/pages/dashboard.tsx`. See `UsageMeter` interface.

**Acceptance Criteria**:

- [ ] Users can see their current usage in the dashboard
- [ ] Webhook handles `meter.updated` events
- [ ] 100% test coverage on `calculateBilling()` function
- [ ] RLS policy scoped to authenticated user only

Technical Constraints

Mention explicit boundaries:

• Files or modules that must NOT be changed
• Performance budgets or size limits
• External service rate limits or API version requirements

Automatic Grooming

Use AI to scan the backlog for quality issues:

• Ambiguity: "This ticket has no acceptance criteria, please clarify"
• Duplication: "This looks 85% similar to ticket PROJ-456"
• Staleness: "This ticket has had no activity for 4+ weeks"
• Technical Debt: "This module has not been touched in 4 months and has open issues"

User Story Template

The standard user story format ensures every ticket captures role, action, and value:

## [FEAT] Export Dashboard as PDF

**As a** billing administrator,
**I want** to export the usage dashboard as a PDF,
**So that** I can share monthly usage reports with stakeholders who do not have app access.

**Context**: Finance team requests monthly PDF reports. Currently they screenshot the dashboard manually.

**Implementation**: Start at `src/features/dashboard/export.ts`. Use the existing `PdfGenerator` utility.

**Acceptance Criteria**:

- [ ] "Export PDF" button visible on dashboard for admin role only
- [ ] PDF includes all visible charts and the date range header
- [ ] PDF file size under 5MB for dashboards with up to 12 months of data
- [ ] Export completes within 10 seconds for standard date ranges
- [ ] Audit log entry created on each export

**Technical Constraints**:

- Must use server-side rendering for PDF (not client-side html2canvas)
- PDF generation must not block the main API thread

Story Anti-Patterns

Task Breakdown Patterns

Vertical Slicing

Slice stories vertically through all layers of the stack, not horizontally by layer:

WRONG (horizontal slices):
  Ticket 1: Build the database schema
  Ticket 2: Build the API endpoints
  Ticket 3: Build the frontend UI

RIGHT (vertical slices):
  Ticket 1: User can view their profile (DB + API + UI for read)
  Ticket 2: User can edit their name (DB + API + UI for write)
  Ticket 3: User can upload an avatar (DB + API + UI + storage)

Vertical slices deliver working functionality at every step. Horizontal slices deliver nothing until all layers are complete.

Walking Skeleton Approach

For new features, start with the thinnest possible end-to-end path:

1. Skeleton ticket: Hardcoded data flows through all layers (DB → API → UI) with no real logic 2. Flesh-out tickets: Replace hardcoded values with real implementations one by one 3. Polish tickets: Error handling, edge cases, performance optimization

## [FEAT] Walking Skeleton — Checkout Flow

**Acceptance Criteria**:

- [ ] Clicking "Buy" sends a request to `/api/checkout`
- [ ] API returns a hardcoded success response
- [ ] UI shows a confirmation page with the hardcoded order ID
- [ ] No real payment processing, no database writes

**Next tickets will add**: Stripe integration, order persistence, email confirmation

Splitting Techniques

When a story is too large for a single sprint:

Estimation Techniques

Planning Poker

The team estimates stories using a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21.

Estimation Flow:
  1. Product owner reads the story and answers questions
  2. Each team member privately selects a point value
  3. All values revealed simultaneously
  4. If estimates diverge (e.g., 3 and 13), the highest and lowest explain their reasoning
  5. Re-vote until consensus (within 1 step on the scale)

Time-box: 5 minutes per story. If no consensus, take the higher estimate.

Point Scale Reference

T-Shirt Sizing

For early-stage estimation when precision is not needed (roadmap planning, epic sizing):

Reference Story Calibration

Anchor the team's estimation scale with well-known reference stories:

**Team Reference Stories:**

- **1 point**: PROJ-42 "Update footer copyright year" (config change, no tests)
- **3 points**: PROJ-108 "Add email field to settings page" (UI + API + migration + tests)
- **5 points**: PROJ-215 "Implement search with Algolia" (new integration, UI, API, indexing)
- **8 points**: PROJ-301 "OAuth with Google and GitHub" (external APIs, token management, error flows)

Re-calibrate reference stories every quarter or when team composition changes significantly.

Priority Frameworks

MoSCoW Method

Categorize stories into four buckets for a given release or sprint:

Value vs Effort Matrix

Plot stories on a 2x2 grid to prioritize visually:

                    High Value
                        │
         Quick Wins     │    Big Bets
        (do first)      │   (plan carefully)
                        │
  Low Effort ───────────┼─────────── High Effort
                        │
         Fill-Ins       │    Money Pit
        (do if idle)    │   (avoid or defer)
                        │
                    Low Value

WSJF (Weighted Shortest Job First)

For teams using SAFe or flow-based prioritization:

WSJF = Cost of Delay / Job Duration

Cost of Delay = User Value + Time Criticality + Risk Reduction

Example:
  Story A: CoD = 8, Duration = 3 → WSJF = 2.67
  Story B: CoD = 5, Duration = 1 → WSJF = 5.00
  → Story B goes first (higher WSJF = higher priority)

WSJF favors small, high-value items. This prevents large, medium-value items from monopolizing the sprint.

Definition of Done Checklist

A story is "done" when all of these are true. The team agrees on this checklist once and applies it to every story:

**Definition of Done:**

- [ ] Code reviewed and approved by at least one other developer
- [ ] All acceptance criteria verified (manually or via automated tests)
- [ ] Unit tests written and passing (no decrease in coverage)
- [ ] Integration tests passing in CI
- [ ] No new lint warnings or type errors introduced
- [ ] Documentation updated (API docs, README, inline docs as needed)
- [ ] Deployed to staging and smoke-tested
- [ ] Product owner has accepted the work on staging
- [ ] No known regressions in related features

DoD vs Acceptance Criteria

A story meets the Definition of Done AND its acceptance criteria before moving to "Done".

Velocity and Risk

Cycle Time Analysis

Cycle time measures how long a ticket takes from "In Progress" to "Merged". This is the primary velocity metric.

• Flag any ticket that exceeds the team's 90th percentile cycle time
• Track trends over sprints to detect degradation early
• Break down cycle time into phases: coding, review, QA, deployment

Lead Time

Lead time measures the full duration from ticket creation to deployment. The gap between lead time and cycle time reveals queue and prioritization bottlenecks.

Context Debt

AI agent performance drops when the project context becomes cluttered or contradictory:

• Risk Indicator: An increase in "fixing previous fix" commits
• Risk Indicator: Growing number of reopened tickets
• Remedy: Schedule a context cleanup sprint to address accumulated inconsistencies, outdated documentation, and conflicting patterns

Integration Friction

If the time spent in "Ready for Review" is increasing, the review process is a bottleneck:

• Implement automated code review for low-level checks (lint, type errors, formatting)
• Reserve human review for architectural decisions and business logic
• Track review turnaround time as a team metric

Probability-Based Burn-Down

The burn-down chart includes a probability cone based on historical data:

• "Based on current velocity and remaining work, there is an 85% chance of hitting the sprint goal by Friday"
• Factor in planned absences, holidays, and known blockers
• Update the forecast daily as new data comes in
• Alert the team when probability drops below 60%

Sprint Metrics Dashboard

Core Metrics

Track these four metrics every sprint to build a complete velocity picture:

Velocity Chart

Points
  40 │          ╭─╮
  35 │    ╭─╮   │ │  ╭─╮
  30 │ ╭─╮│ │╭─╮│ │  │ │
  25 │ │ ││ ││ ││ │╭─╮ │
  20 │ │ ││ ││ ││ ││ ││ │
     └─┴─┴┴─┴┴─┴┴─┴┴─┴┴─┴──
      S8  S9  S10 S11 S12 S13

Average velocity (last 3): 34 points
Trend: Stable (within ±10%)

Use the average of the last 3 sprints for planning. Ignore outlier sprints (holidays, team changes) when calculating averages.

Burndown vs Burnup

Burndown shows remaining work decreasing over the sprint. It is simple but hides scope changes.

Burnup shows two lines: total scope and completed work. When the scope line moves up mid-sprint, the burnup chart makes that visible. Prefer burnup for sprints where scope changes are common.

Burnup Chart — Sprint 13
Points
  40 │                    ╱── Total Scope (grew mid-sprint)
  35 │              ╱────╱
  30 │        ╱────╱
  25 │  ╱────╱            ╱── Completed
  20 │─╱            ╱────╱
  15 │        ╱────╱
  10 │  ╱────╱
   5 │─╱
     └────────────────────
      D1  D3  D5  D7  D9

Cycle Time Distribution

Track cycle time as a histogram to identify patterns:

Tickets
  12 │  ██
  10 │  ██ ██
   8 │  ██ ██ ██
   6 │  ██ ██ ██ ██
   4 │  ██ ██ ██ ██ ██
   2 │  ██ ██ ██ ██ ██ ██
     └──────────────────────
      1d  2d  3d  5d  8d  13d+

Median: 3 days | 85th percentile: 5 days | Outliers: 2 tickets at 13+ days

Investigate any ticket beyond the 85th percentile. These outliers often reveal systemic issues (unclear requirements, dependency bottlenecks, knowledge silos).

Risk Management

Dependency Mapping Between Stories

Dependencies within a sprint create critical paths. Map them explicitly:

PROJ-101 (Auth API)
  └─ blocks → PROJ-102 (Login UI)
  └─ blocks → PROJ-103 (OAuth Flow)
                └─ blocks → PROJ-104 (Social Login)

PROJ-105 (DB Migration)
  └─ blocks → PROJ-106 (New Dashboard)

Rules for dependency management:

• No more than 2 levels of dependency within a sprint
• Stories with 3+ dependents are critical path items — assign the strongest developer
• External dependencies (other teams, third-party APIs) get a risk buffer of +50% estimated time
• If a blocking story slips, immediately re-evaluate all downstream stories

Critical Path Identification

The critical path is the longest chain of dependent stories in the sprint. If any story on the critical path slips, the sprint goal is at risk.

Sprint Critical Path Analysis:

Path 1: PROJ-101 → PROJ-102 → PROJ-104 (total: 13 points, 3 stories)
Path 2: PROJ-105 → PROJ-106 (total: 8 points, 2 stories)

Critical path: Path 1 (longest chain)
Risk: PROJ-101 is estimated at 5 points and has an external API dependency
Mitigation: Start PROJ-101 on day 1, pair with senior developer

Risk Register

Maintain a living risk register for the sprint:

Risk score = Probability (1-3) x Impact (1-3). Address scores of 6+ immediately. Monitor scores of 3-5. Accept scores below 3.

Risk Response Strategies

Distributed Team Patterns

Async Standups

For teams spanning 3+ timezones, replace synchronous standups with async summaries:

### Async Standup Template (Slack / Teams)

**What I completed since last update:**

- Merged PR #234 (search indexing)
- Fixed flaky test in billing module

**What I am working on today:**

- PROJ-108: API endpoint for export feature

**Blockers:**

- None

**Availability:**

- Available 9am-5pm EST, OOO Thursday afternoon

Post async standups in a dedicated channel. The AI scrum conductor aggregates updates and flags gaps (missed updates, stale blockers, conflicting work).

Timezone-Aware Sprint Ceremonies

Overlap Hours Strategy

Identify the window where all (or most) timezones overlap:

Team Distribution:
  US Pacific (UTC-8):  9am-5pm  →  17:00-01:00 UTC
  US Eastern (UTC-5):  9am-5pm  →  14:00-22:00 UTC
  Central Europe (UTC+1): 9am-5pm → 08:00-16:00 UTC
  India (UTC+5:30):    9am-5pm  →  03:30-11:30 UTC

Overlap (US East + Europe): 14:00-16:00 UTC (2 hours)
Overlap (all four): None — use async for India, sync for US+Europe

Protect overlap hours for synchronous ceremonies and critical discussions. Do not schedule non-essential meetings during overlap time.

Release Planning

Multi-Sprint Roadmap

Plan releases across 3-6 sprints with decreasing confidence:

Update the roadmap every sprint during sprint planning. Stakeholders should see confidence levels, not fixed promises.

Release Train Concept

For larger teams, coordinate multiple squads releasing on a fixed cadence:

• Release cadence: Every 2-4 sprints (e.g., monthly)
• Feature freeze: 2-3 days before release for stabilization
• Release criteria: All stories meet Definition of Done, no P0/P1 bugs open, staging smoke tests pass
• Rollback plan: Feature flags allow disabling individual features without a full rollback

Feature Flags for Incremental Delivery

Decouple deployment from release using feature flags:

Feature Flag Strategy:

1. Deploy code behind a flag (off by default)
2. Enable for internal team first (dogfooding)
3. Enable for 5% of users (canary release)
4. Monitor error rates and performance for 24-48 hours
5. Ramp to 25% → 50% → 100% over days
6. Remove the flag after full rollout is stable for 1 sprint

Flag hygiene:

• Every flag has an owner and an expiration date
• Flags older than 2 sprints without progress get flagged in backlog grooming
• Maximum 10 active feature flags at any time (more creates testing complexity)
• Dead flags (fully rolled out or abandoned) are removed as tech debt tickets