Scrum Master

Scrum Master Expert

The agent acts as a data-driven Scrum Master combining sprint analytics, behavioral science, and continuous improvement methodologies. It analyzes velocity trends, scores sprint health across 6 dimensions, identifies retrospective patterns, and recommends stage-specific coaching interventions.

Core Capabilities

• Sprint health scoring — 6 weighted dimensions (commitment reliability, scope stability, blocker resolution, ceremony engagement, completion distribution, velocity predictability) → 0-100 grade.
• Velocity forecasting — Monte Carlo simulation with rolling averages, trend detection, anomaly flags, and 50/70/85/95% confidence intervals.
• Retrospective analysis — action-item completion tracking, recurring-theme persistence, sentiment trends, and team-maturity assessment.
• Capacity planning — per-member availability, ceremony overhead, and focus factor → conservative/realistic/optimistic commitment.
• Team coaching — maps behavior to Tuckman stages and Edmondson psychological-safety signals, recommending stage-specific interventions.

When to Use

• Facilitating sprint planning and setting a sustainable commitment level
• Diagnosing velocity drops, high volatility, or wide forecast intervals
• Running retrospectives and tracking whether action items actually land
• Calculating team capacity with PTO, allocation, and ceremony overhead
• Coaching a team through Tuckman development stages

Clarify First

Before running the analysis, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] Which analysis — velocity forecast, sprint health score, capacity plan, or retro analysis (each selects a different tool and output)
• [ ] Historical sprint data — how many sprints of data exist (Monte Carlo forecasting needs 3+ sprints, 6+ recommended; less means high-uncertainty output)
• [ ] Team capacity context — size, PTO/allocation, ceremony overhead (drives the realistic-vs-optimistic commitment numbers)
• [ ] Team development stage — Tuckman stage / known dynamics (sets which coaching interventions the output recommends)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

All tools accept JSON following assets/sample_sprint_data.json. The full 6-step workflow, input schema, and a worked forecast example are in references/workflow-and-operations.md.

Templates & Assets

• assets/sprint_report_template.md -- Sprint report with health grade, velocity trends, quality metrics
• assets/team_health_check_template.md -- Spotify Squad Health Check adaptation (9 dimensions)
• assets/sample_sprint_data.json -- 6-sprint dataset for testing tools
• assets/expected_output.json -- Reference outputs (velocity avg 20.2, health 78.3/100)
• assets/user_story_template.md -- Classic and Job Story formats with INVEST criteria
• assets/sprint_plan_template.md -- Sprint plan with capacity, commitments, risks

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• [references/workflow-and-operations.md](references/workflow-and-operations.md) — the 6-step workflow (assess → health → forecast → capacity → retro → coach) with commands, validation checkpoints, the 6-dimension and Tuckman tables, a worked forecast example, and the JSON input schema. Read when running an end-to-end engagement.
• [references/metrics-troubleshooting-and-tools.md](references/metrics-troubleshooting-and-tools.md) — key metrics & targets, troubleshooting table, success criteria, and the full flag reference for all four tools. Read when setting targets, diagnosing problems, or scripting the tools.
• [references/velocity-forecasting-guide.md](references/velocity-forecasting-guide.md) — Monte Carlo implementation, confidence intervals, seasonality adjustment. Read when interpreting or tuning forecasts.
• [references/team-dynamics-framework.md](references/team-dynamics-framework.md) — Tuckman's stages, psychological safety building, conflict resolution. Read when coaching team development.
• [references/sprint-planning-guide.md](references/sprint-planning-guide.md) — pre-planning checklist, SMART goals, capacity methodology. Read when facilitating planning.
• [references/retro-formats.md](references/retro-formats.md) — retrospective formats and facilitation patterns. Read when designing a retro.
• [references/red-flags.md](references/red-flags.md) — anti-patterns and warning signs in Scrum practice. Read when something on the team feels off.

Scope & Limitations

In Scope:

• Sprint-level data analysis (velocity, health, capacity, retrospectives)
• Statistical forecasting using Monte Carlo simulation on historical velocity
• Team dynamics coaching based on Tuckman model and Edmondson psychological safety
• Ceremony facilitation guidance and retrospective pattern analysis

Out of Scope:

• Portfolio-level project management (see senior-pm/ skill)
• Product backlog prioritization and roadmap decisions (see execution/prioritization-frameworks/)
• Individual performance evaluation -- this skill measures team-level metrics only
• Real-time Jira/Confluence integration (see jira-expert/ and confluence-expert/ skills)
• SAFe-specific PI planning or cross-team dependency management (see program-manager/)

Important Caveats:

• The Scrum Guide 2020 removed "velocity" as a required artifact; this skill treats velocity as a diagnostic tool, not a performance measure. Use flow metrics (cycle time, throughput, WIP) alongside velocity.
• Monte Carlo forecasts require minimum 3 sprints of data (6+ recommended); forecasts with fewer data points carry high uncertainty.
• Health scores are heuristics, not absolute measures. Calibrate dimension weights to your team context.

Integration Points

Sprint [NUMBER] Plan - [SPRINT_NAME]

Team: [TEAM_NAME] Scrum Master: [SCRUM_MASTER_NAME] Product Owner: [PRODUCT_OWNER_NAME] Sprint Period: [START_DATE] to [END_DATE] Sprint Length: [DAYS] working days Planning Date: [PLANNING_DATE]

---

Sprint Goal

[One clear, concise statement of what the team aims to achieve this sprint. Should follow SMART format and align with product goals.]

Success Criteria

• [ ] [MEASURABLE_CRITERION_1]
• [ ] [MEASURABLE_CRITERION_2]
• [ ] [MEASURABLE_CRITERION_3]

Product Goal Alignment

Product Goal: [PRODUCT_GOAL_OR_OKR] How This Sprint Contributes: [BRIEF_EXPLANATION]

---

Team Capacity Summary

Team Availability

Capacity Allocation Breakdown

Velocity Reference

---

Committed Stories

Carry-Over from Previous Sprint

---

Stretch Goals

These stories will be pulled in only if the team completes all committed work early. They are NOT part of the sprint commitment.

---

Dependencies

Internal Dependencies (Within This Sprint)

External Dependencies (Outside the Team)

---

Risks

---

Sprint Calendar

Ceremony Schedule

Key Dates

• Mid-Sprint Check: [DATE] - Assess progress against sprint goal
• Code Freeze: [DATE] (if applicable)
• QA Window: [START_DATE] to [END_DATE]
• Release Date: [DATE] (if applicable)

Team PTO / Out-of-Office

---

Definition of Done Reminder

Every story must meet the Definition of Done before it is considered complete:

• [ ] Code is written and follows team coding standards
• [ ] Unit tests written and passing
• [ ] Code reviewed and approved by at least one peer
• [ ] Integration tests passing
• [ ] Documentation updated (if applicable)
• [ ] Acceptance criteria verified by Product Owner
• [ ] No known defects or regressions
• [ ] Deployed to staging environment

---

Notes from Sprint Planning

Decisions Made

• [DECISION_1]
• [DECISION_2]

Open Questions

Parking Lot Items

• [ITEM_1] - To be discussed in [MEETING/CHANNEL]
• [ITEM_2] - Deferred to next refinement

---

Plan created by: [SCRUM_MASTER_NAME] Plan confirmed by team: [YES/NO] on [DATE] Distribution: Development Team, Product Owner, Stakeholders

--- Use this plan as the single source of truth for the sprint. Update story status daily. Review capacity and progress at mid-sprint. Refer to the sprint goal when making scope decisions.

Sprint [NUMBER] - [SPRINT_NAME] Report

Team: [TEAM_NAME] Scrum Master: [SCRUM_MASTER_NAME] Sprint Period: [START_DATE] to [END_DATE] Report Date: [REPORT_DATE]

---

Executive Summary

Sprint Goal Achievement: [ACHIEVED/PARTIALLY_ACHIEVED/NOT_ACHIEVED] Overall Health Grade: [EXCELLENT/GOOD/FAIR/POOR] ([HEALTH_SCORE]/100) Velocity: [COMPLETED_POINTS] points ([VELOCITY_TREND] from previous sprint) Commitment Ratio: [COMMITMENT_PERCENTAGE]% of planned work completed

Key Highlights

• [KEY_ACHIEVEMENT_1]
• [KEY_ACHIEVEMENT_2]
• [KEY_CHALLENGE_1]
• [KEY_CHALLENGE_2]

---

Sprint Metrics Dashboard

Delivery Performance

Process Health

Quality Indicators

---

User Stories Delivered

Completed Stories ([COMPLETED_COUNT])

In Progress Stories ([IN_PROGRESS_COUNT])

Blocked Stories ([BLOCKED_COUNT])

---

Blockers & Impediments

Resolved This Sprint ([RESOLVED_BLOCKERS_COUNT])

Active Blockers ([ACTIVE_BLOCKERS_COUNT])

Escalation Required

• [ESCALATION_ITEM_1]
• [ESCALATION_ITEM_2]

---

Team Performance Analysis

Velocity Trend

Sprint [N-2]: [VELOCITY_N2] points
Sprint [N-1]: [VELOCITY_N1] points  
Sprint [N]:   [VELOCITY_N] points
Trend: [IMPROVING/STABLE/DECLINING] ([TREND_PERCENTAGE]% change)

Predictability Assessment

• Coefficient of Variation: [CV_PERCENTAGE]% ([HIGH/MODERATE/LOW] volatility)
• Commitment Reliability: [COMMITMENT_RELIABILITY_SCORE]/100
• Forecast Confidence: [FORECAST_CONFIDENCE]% for next sprint

Team Health Indicators

---

Retrospective Insights

What Went Well

• [WENT_WELL_1]
• [WENT_WELL_2]
• [WENT_WELL_3]

Areas for Improvement

• [IMPROVE_1]
• [IMPROVE_2]
• [IMPROVE_3]

Action Items from Retrospective

Previous Sprint Action Items Follow-up

---

Risks & Dependencies

High Priority Risks

External Dependencies

---

Looking Ahead: Next Sprint

Sprint Goals

1. [GOAL_1] 2. [GOAL_2] 3. [GOAL_3]

Planned Capacity

• Team Size: [TEAM_SIZE] members
• Available Capacity: [AVAILABLE_HOURS] hours ([CAPACITY_POINTS] points)
• Planned Velocity: [PLANNED_VELOCITY] points
• Capacity Buffer: [BUFFER_PERCENTAGE]% for unknowns

Key Focus Areas

• [FOCUS_AREA_1]
• [FOCUS_AREA_2]
• [FOCUS_AREA_3]

Dependencies to Monitor

• [MONITOR_DEP_1]
• [MONITOR_DEP_2]

---

Recommendations

Immediate Actions (This Sprint)

1. [HIGH_PRIORITY_ACTION_1] - [DESCRIPTION] (Owner: [OWNER], Due: [DATE]) 2. [HIGH_PRIORITY_ACTION_2] - [DESCRIPTION] (Owner: [OWNER], Due: [DATE])

Process Improvements (Next 2-3 Sprints)

1. [PROCESS_IMPROVEMENT_1] - [DESCRIPTION] 2. [PROCESS_IMPROVEMENT_2] - [DESCRIPTION]

Team Development Opportunities

1. [DEVELOPMENT_1] - [DESCRIPTION] 2. [DEVELOPMENT_2] - [DESCRIPTION]

---

Appendix

Sprint Burndown Chart

[BURNDOWN_CHART_REFERENCE]

Detailed Metrics

[DETAILED_METRICS_REFERENCE]

Team Feedback

[TEAM_FEEDBACK_SUMMARY]

---

Report prepared by: [SCRUM_MASTER_NAME] Next review date: [NEXT_REVIEW_DATE] Distribution: Product Owner, Development Team, Stakeholders

--- This report is generated using standardized sprint health metrics and retrospective analysis. For questions or deeper analysis, please contact the Scrum Master.

Team Health Check - Spotify Squad Model

Team: [TEAM_NAME] Assessment Date: [DATE] Facilitator: [FACILITATOR_NAME] Participants: [PARTICIPANT_COUNT] of [TOTAL_TEAM_SIZE] members

---

Health Check Overview

The Team Health Check is based on Spotify's Squad Health Check model, designed to visualize team health across multiple dimensions. Each dimension is assessed using a simple traffic light system:

• 🟢 Green (Awesome): We're doing great! No major concerns.
• 🟡 Yellow (Some Concerns): We're doing okay, but there are some things we could improve.
• 🔴 Red (Not Good): This really sucks and we need to do something about it.

Assessment Method

• Anonymous individual ratings followed by team discussion
• Focus on trends over time rather than absolute scores
• Action-oriented outcomes for improvement areas

---

Health Dimensions Assessment

1. Delivering Value 🎯

Are we delivering value to our users and stakeholders?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

2. Learning 📚

Are we learning and growing as individuals and as a team?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

3. Fun 🎉

Do we enjoy working together and find our work engaging?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

4. Health of Codebase 🏗️

Is our code healthy, maintainable, and of good quality?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

5. Mission Clarity 🎯

Do we understand why we exist and what we're supposed to achieve?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

6. Suitable Process ⚙️

Is our process helping us be effective?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

7. Support 🤝

Do we get the support we need from management and other teams?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

8. Speed ⚡

Are we able to deliver quickly without compromising quality?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

9. Pawns or Players 👥

Do we feel like we have control over our work and destiny?

Current Status: [🟢/🟡/🔴] Trend from Last Check: [⬆️ Improving / ➡️ Stable / ⬇️ Declining] Team Rating: [X]/5 team members voted Green, [Y]/5 Yellow, [Z]/5 Red

What's Working Well:

• [POSITIVE_POINT_1]
• [POSITIVE_POINT_2]

Areas of Concern:

• [CONCERN_1]
• [CONCERN_2]

Suggested Actions:

• [ACTION_1]
• [ACTION_2]

---

Overall Health Summary

Health Score Distribution

• 🟢 Green Dimensions: [GREEN_COUNT]/9 ([GREEN_PERCENTAGE]%)
• 🟡 Yellow Dimensions: [YELLOW_COUNT]/9 ([YELLOW_PERCENTAGE]%)
• 🔴 Red Dimensions: [RED_COUNT]/9 ([RED_PERCENTAGE]%)

Overall Health Grade: [EXCELLENT/GOOD/FAIR/POOR]

Trend Analysis

• Improving: [IMPROVING_COUNT] dimensions
• Stable: [STABLE_COUNT] dimensions
• Declining: [DECLINING_COUNT] dimensions

Team Maturity Level

Based on the health check results and team dynamics observed: [FORMING/STORMING/NORMING/PERFORMING/ADJOURNING]

---

Priority Action Items

High Priority (Red Dimensions)

1. [RED_DIMENSION_1]: [ACTION_DESCRIPTION_1]

• Owner: [OWNER_1]
• Timeline: [TIMELINE_1]
• Success Criteria: [CRITERIA_1]

2. [RED_DIMENSION_2]: [ACTION_DESCRIPTION_2]

• Owner: [OWNER_2]
• Timeline: [TIMELINE_2]
• Success Criteria: [CRITERIA_2]

Medium Priority (Yellow Dimensions)

1. [YELLOW_DIMENSION_1]: [ACTION_DESCRIPTION_1]

• Owner: [OWNER_1]
• Timeline: [TIMELINE_1]

2. [YELLOW_DIMENSION_2]: [ACTION_DESCRIPTION_2]

• Owner: [OWNER_2]
• Timeline: [TIMELINE_2]

Maintain Strengths (Green Dimensions)

1. [GREEN_DIMENSION_1]: Continue [STRENGTH_PRACTICE_1] 2. [GREEN_DIMENSION_2]: Share [BEST_PRACTICE_1] with other teams

---

Psychological Safety Assessment

Separate anonymous assessment of team psychological safety

Psychological Safety Indicators

1. Speaking Up: Team members feel safe to speak up with ideas, questions, concerns, or mistakes

• Score: [SCORE_1]/5 ⭐⭐⭐⭐⭐

2. Risk Taking: Team members feel safe to take risks and make mistakes

• Score: [SCORE_2]/5 ⭐⭐⭐⭐⭐

3. Asking for Help: Team members feel comfortable asking for help or admitting they don't know something

• Score: [SCORE_3]/5 ⭐⭐⭐⭐⭐

4. Discussing Problems: Difficult topics and problems can be discussed openly

• Score: [SCORE_4]/5 ⭐⭐⭐⭐⭐

5. Being Yourself: Team members don't feel they have to pretend to be someone else

• Score: [SCORE_5]/5 ⭐⭐⭐⭐⭐

Overall Psychological Safety Score: [TOTAL_SCORE]/25

Psychological Safety Actions

• [PSYCH_SAFETY_ACTION_1]
• [PSYCH_SAFETY_ACTION_2]

---

Communication & Collaboration Assessment

Communication Quality

• Clarity of Communication: [SCORE]/5 ⭐⭐⭐⭐⭐
• Frequency of Communication: [SCORE]/5 ⭐⭐⭐⭐⭐
• Openness & Transparency: [SCORE]/5 ⭐⭐⭐⭐⭐

Collaboration Patterns

• Cross-functional Collaboration: [SCORE]/5 ⭐⭐⭐⭐⭐
• Knowledge Sharing: [SCORE]/5 ⭐⭐⭐⭐⭐
• Conflict Resolution: [SCORE]/5 ⭐⭐⭐⭐⭐

---

Follow-up Plan

Next Health Check

Scheduled Date: [NEXT_DATE] Frequency: [MONTHLY/QUARTERLY/BI-ANNUAL]

Interim Check-ins

• Sprint Retrospectives: Continue monitoring health indicators
• Weekly 1:1s: Individual pulse checks with team members
• Monthly Team Lunches: Informal health and morale assessment

Success Metrics

We'll know we're improving when we see:

• [SUCCESS_METRIC_1]
• [SUCCESS_METRIC_2]
• [SUCCESS_METRIC_3]

---

Historical Comparison

Previous Health Checks

Long-term Improvements

• [LONG_TERM_IMPROVEMENT_1]
• [LONG_TERM_IMPROVEMENT_2]

Persistent Challenges

• [PERSISTENT_CHALLENGE_1]
• [PERSISTENT_CHALLENGE_2]

---

Team Comments & Feedback

Anonymous feedback from team members

What's the most important thing we should focus on?

• "[FEEDBACK_1]"
• "[FEEDBACK_2]"
• "[FEEDBACK_3]"

What's our biggest strength as a team?

• "[STRENGTH_1]"
• "[STRENGTH_2]"
• "[STRENGTH_3]"

If you could change one thing, what would it be?

• "[CHANGE_1]"
• "[CHANGE_2]"
• "[CHANGE_3]"

---

Action Item Summary

---

Assessment completed by: [FACILITATOR_NAME] Report distribution: Team Members, Product Owner, Management (summary only) Confidentiality: Individual responses kept confidential, only aggregate data shared

--- This health check is based on the Spotify Squad Health Check model. The goal is continuous improvement, not judgment. Use this data to have better conversations about how to work together effectively.

User Story Template

Story ID: [PROJECT]-[NUMBER] Epic: [EPIC_NAME] Sprint: [SPRINT_NUMBER] (if assigned) Author: [AUTHOR_NAME] Date Created: [DATE] Last Updated: [DATE]

---

Story Format

Option A: Classic User Story

As a [type of user/role],

I want [action or capability],

so that [benefit or value].

Option B: Job Story

When [situation or trigger],

I want to [motivation or action],

so I can [expected outcome].

Choose the format that best fits the context:

• Use User Story when the role and persona are important to the requirement
• Use Job Story when the context and situation drive the need

---

Story Details

Description

[Provide 2-3 sentences of additional context. Explain the user's problem, the business need, or the technical background. This supplements the story statement above.]

3 C's Framework

---

INVEST Criteria Checklist

Before this story is considered ready for sprint planning, verify it meets INVEST:

• [ ] Independent - Can be developed without depending on other stories in this sprint
• [ ] Negotiable - Implementation details are flexible; the team decides the "how"
• [ ] Valuable - Delivers clear value to the user or business
• [ ] Estimable - Team can estimate the effort with reasonable confidence
• [ ] Small - Can be completed within a single sprint
• [ ] Testable - Has clear, verifiable acceptance criteria

---

Acceptance Criteria

Write acceptance criteria using the Given/When/Then format:

Criterion 1: [SHORT_DESCRIPTION]

Given [precondition or initial context]
When  [action performed by the user or system]
Then  [expected result or observable outcome]

Criterion 2: [SHORT_DESCRIPTION]

Given [precondition or initial context]
When  [action performed by the user or system]
Then  [expected result or observable outcome]

Criterion 3: [SHORT_DESCRIPTION]

Given [precondition or initial context]
When  [action performed by the user or system]
Then  [expected result or observable outcome]

Edge Cases / Negative Scenarios

Given [unusual or error condition]
When  [user attempts the action]
Then  [system handles gracefully with appropriate feedback]

---

Definition of Ready Checklist

This story is ready for sprint planning when ALL items are checked:

• [ ] Story statement is complete (User Story or Job Story format)
• [ ] Acceptance criteria are written and reviewed by the Product Owner
• [ ] Story points are assigned by the team
• [ ] Dependencies are identified and documented below
• [ ] UX designs or wireframes are attached (if applicable)
• [ ] Technical approach is understood by at least 2 team members
• [ ] No open questions remain (or questions are documented with owners)
• [ ] Story fits within a single sprint at estimated size

---

Story Metadata

Sizing

• Story Points: [POINTS]
• T-Shirt Size: [XS / S / M / L / XL]
• Estimated Hours: [HOURS] (optional, for capacity planning)

Classification

• Type: [Feature / Bug Fix / Technical Debt / Spike / Improvement]
• Priority: [Critical / High / Medium / Low]
• Risk Level: [High / Medium / Low]

Dependencies

Related Items

• Parent Epic: [EPIC_ID] - [EPIC_NAME]
• Blocked By: [STORY_ID] (if any)
• Blocks: [STORY_ID] (if any)
• Related Stories: [STORY_ID_1], [STORY_ID_2]

---

Story Splitting Strategies

If this story is too large (>8 points or won't fit in a sprint), consider these splitting techniques:

1. Split by Workflow Steps

Break a multi-step process into individual steps:

• Story A: User can initiate the process
• Story B: User can complete step 2
• Story C: User receives confirmation

2. Split by Business Rules

Separate simple and complex rules:

• Story A: Basic validation (required fields)
• Story B: Advanced validation (cross-field rules)
• Story C: Edge case handling

3. Split by Data Variations

Handle different data types or inputs separately:

• Story A: Support text input
• Story B: Support file upload
• Story C: Support bulk import

4. Split by Operations (CRUD)

Separate create, read, update, delete:

• Story A: User can create a record
• Story B: User can view records
• Story C: User can edit a record
• Story D: User can delete a record

5. Split by Interface

Separate platforms or interaction modes:

• Story A: Web interface
• Story B: Mobile interface
• Story C: API endpoint

6. Split by Performance

Deliver functionality first, optimize second:

• Story A: Feature works (basic implementation)
• Story B: Feature performs at scale (optimization)

7. Spike + Implementation

Separate research from execution:

• Spike: Investigate approach for [complex area] (timeboxed)
• Story: Implement [feature] based on spike findings

---

Example Stories

Example 1: Small Story (1-2 points)

As a registered user,

I want to update my display name in account settings,

so that my name appears correctly across the application.

Acceptance Criteria:

Given I am logged in and on the Account Settings page
When  I enter a new display name and click Save
Then  my display name is updated and a success message is shown

Given I enter a display name longer than 50 characters
When  I click Save
Then  the system shows a validation error and does not save

Points: 2 | Type: Feature | Risk: Low

---

Example 2: Medium Story (3-5 points)

When I receive a weekly project status email,

I want to see a summary of sprint progress and blockers,

so I can quickly assess project health without opening multiple tools.

Acceptance Criteria:

Given it is Monday at 9:00 AM
When  the automated email is triggered
Then  all project stakeholders receive an email with velocity, burndown, and active blockers

Given there are no active blockers
When  the email is generated
Then  the blockers section shows "No active blockers" instead of being empty

Points: 5 | Type: Feature | Risk: Medium

---

Example 3: Large Story (8 points - consider splitting)

As a team administrator,

I want to configure custom workflow states and transitions,

so that the tool matches our team's actual development process.

Acceptance Criteria:

Given I am on the Workflow Configuration page
When  I add a new state and define transitions
Then  the workflow is updated and visible to all team members

Given a workflow state has active items
When  I attempt to delete that state
Then  the system prevents deletion and shows affected items

Points: 8 | Type: Feature | Risk: High Note: Consider splitting into: (A) Add/remove states, (B) Define transitions, (C) Validation and error handling

---

Notes & Discussion Log

---

Template maintained by the Scrum Master. Use this template for all new user stories to ensure consistency and readiness for sprint planning.

Example: Sprint Health Analysis for a 7-Person Team

Real-world scenario showing how to apply this skill end-to-end.

Context

Acme Analytics' Search Platform team (B2B analytics SaaS, Series B, 80 people) has 7 engineers + 1 designer + 1 PM. The Scrum Master (Mira) has been with the team for 9 sprints. Velocity is volatile (16 to 38 points), commitments are missed at a 40% rate, and at the last retro three engineers said they felt the sprint goal was "set and then ignored." Mira is running a data-driven health analysis to put numbers on the discomfort.

The team uses 2-week sprints. This analysis covers the last 6 sprints (Sprints 18-23) and produces: a velocity trend, a sprint health scorecard across 6 dimensions, a Monte Carlo forecast of Sprint 24 capacity, and a retrospective action plan.

Inputs

• 6 sprints of historical data (Sprints 18-23)
• Team size: 7 engineers + 1 designer + 1 PM
• Sprint length: 2 weeks
• Ceremony overhead: ~12% of capacity
• Holidays in window: 1 day (Memorial Day, Sprint 22)
• Known: 2 production incidents during the window (Sprints 19, 22)

Applying the skill

1. Capture sprint data in JSON. 2. Run `velocity_analyzer.py` for trend + Monte Carlo forecast. 3. Run `sprint_health_scorer.py` for the 6-dimension scorecard. 4. Run `retrospective_analyzer.py` on retro notes to surface recurring themes. 5. Build a Sprint 24 capacity plan that accounts for the Monte Carlo range. 6. Produce one consolidated artifact for the team and the engineering lead.

The artifact

Command 1: velocity analysis

python scripts/velocity_analyzer.py sprint_data.json --format text

Output (excerpt)

=== Search Platform Velocity Analysis (Sprints 18-23) ===

Sprint   Committed   Completed   Goal hit
S18      32          28          partial
S19      30          18          missed   (incident)
S20      28          26          hit
S21      34          22          missed
S22      30          24          partial  (holiday + incident)
S23      32          38          hit (carry-over)

Mean velocity:           26.0 points
Median velocity:         25.0 points
Std dev:                  6.6 points
CV (coefficient of variation): 25.4% (target <20%, current ABOVE)

Trend (linear regression slope): +0.3 pts/sprint (essentially flat)

=== Monte Carlo Forecast (10,000 runs) for Sprint 24 ===

50% confidence: 22 points
75% confidence: 18 points
85% confidence: 16 points
95% confidence: 13 points

RECOMMENDED COMMITMENT: 18-22 points (75-50% confidence band)

Command 2: sprint health scorer

python scripts/sprint_health_scorer.py sprint_data.json --format text

Output

=== Sprint Health Scorecard (Sprints 18-23) ===

Dimension                     Weight   Score   Weighted
Commitment Reliability        25%      52      13.0
Scope Stability               20%      48      9.6
Blocker Resolution            15%      71      10.7
Ceremony Engagement           15%      82      12.3
Story Completion Distribution 15%      63      9.4
Velocity Predictability       10%      55      5.5

----------------------------------------------------
OVERALL HEALTH SCORE: 60.5 / 100  (GRADE: D+)

----------------------------------------------------
DIMENSION BREAKDOWNS

Commitment Reliability (52):
  - 2 of 6 sprints hit goal cleanly (33%)
  - 2 partial, 2 missed
  - Pattern: missed sprints had a production incident OR mid-sprint scope add

Scope Stability (48):
  - Mean mid-sprint scope adds: 4.3 per sprint
  - Largest add: S21 +9 points day-3
  - Pattern: PM accepting CRO escalations mid-sprint

Blocker Resolution (71):
  - Median time-to-resolve: 1.4 days
  - 80% of blockers resolved within SLA (target 75%)

Ceremony Engagement (82):
  - High attendance and quality across all ceremonies
  - One bright spot

Story Completion Distribution (63):
  - 68% of started stories completed in sprint
  - 12 carry-over stories across window (avg 2/sprint)

Velocity Predictability (55):
  - CV 25.4% (target <20%)
  - Excluding incident sprints, CV drops to 14% -- driver is incidents

----------------------------------------------------
INTERVENTION PRIORITY (top 3)

1. Scope Stability -- protect the sprint goal from mid-sprint adds (PM)
2. Commitment Reliability -- right-size commitment using Monte Carlo (Scrum Master)
3. Velocity Predictability -- reduce incident load or buffer for it (Eng Lead)

Command 3: retro analyzer

python scripts/retrospective_analyzer.py sprint_data.json --format text

Output (excerpt)

=== Recurring themes across last 6 retros ===

"Sprint goal felt theoretical"                appearances: 4
"Mid-sprint reprioritization"                  appearances: 5
"Pairing during incidents was disorganized"    appearances: 3
"Story splitting could be tighter"             appearances: 3
"Demos rushed at sprint end"                   appearances: 2
"Tooling for telemetry rebuild was painful"    appearances: 2

ACTION ITEMS FOLLOW-THROUGH

Sprint 18 actions:  2 of 3 completed
Sprint 19 actions:  1 of 2 completed
Sprint 20 actions:  3 of 3 completed
Sprint 21 actions:  1 of 4 completed     <- alarm
Sprint 22 actions:  2 of 3 completed
Sprint 23 actions:  2 of 3 completed

Follow-through rate: 11/18 (61%) -- BELOW healthy threshold (75%)

Sprint 24 capacity plan

Based on Monte Carlo + retro analysis:

Retrospective action plan (committed)

Trend visualization

graph LR
    S18[S18: 28/32] --> S19[S19: 18/30 incident]
    S19 --> S20[S20: 26/28]
    S20 --> S21[S21: 22/34 scope+9]
    S21 --> S22[S22: 24/30 holiday+incident]
    S22 --> S23[S23: 38/32 carry-over recovery]
    S23 --> S24[S24 target: 18-22]
    style S19 fill:#fda4af
    style S21 fill:#fda4af
    style S22 fill:#fde68a
    style S24 fill:#bbf7d0

One-page summary for the engineering lead

Search Platform health is D+ (60.5/100). Two of three drivers are PM-controllable (scope stability, right-sized commitment). The third (incident load) is operational; we are budgeting for it explicitly in S24.

>

Sprint 24 commitment: 18-22 points (was 30-34). This is not a "lower goals" exercise -- it is a Monte Carlo-derived realistic range. Hitting commitments restores the team's trust in the sprint goal, which was the #1 retro theme.

>

Three actions land in Sprint 24: scope-add policy, right-sized commitment, incident reserve. We will re-score at the S25 retro.

Why this works

• Uses all three sprint analysis tools (velocity, health, retro). Each surfaces a different lens.
• Health scorecard has weighted dimensions, not just a single number. The intervention priority is data-derived, not opinion.
• Monte Carlo forecast produces a range (50/75/85/95% confidence), not a single point estimate. The team commits to a band, not a brittle number.
• Capacity calculation accounts for PTO, ceremonies, and an incident reserve. The 10% incident reserve is justified by the historical data, not guessed.
• Retro analysis catches recurring themes ("sprint goal felt theoretical" 4 times) that single-sprint reads would miss.
• Action items are anchored to health dimensions. Each action is owned, dated, and trackable.

What's next

• Re-run sprint_health_scorer.py after Sprints 25 and 26; expect Commitment Reliability to climb to 70+ if Action 1 + 2 land.
• Use ../sprint-retrospective/ for the next data-driven retro (S24 close).
• Feed sprint outcomes into ../execution/status-update-generator/ for the weekly exec update.
• Cross-reference scope stability data with ../execution/dependency-map/ to see which adds came from cross-team escalations.
• Coach the PM via ../career/pm-1on1s/ on the scope-add policy enforcement.

Key Metrics, Troubleshooting, Success Criteria & Tool Reference

Read this when setting team targets, diagnosing a sprint-analytics problem, checking whether coaching met its bar, or looking up the exact flags for any of the four Python tools.

Key Metrics & Targets

Troubleshooting

Success Criteria

• Sprint health score consistently above 80/100 across 6-dimension assessment
• Velocity coefficient of variation (CV) maintained below 20% over rolling 6-sprint window
• Sprint commitment reliability exceeds 85% (completed vs. planned points)
• Action item completion rate from retrospectives exceeds 70% by next retro
• Blocker average resolution time under 3 working days
• Team maturity advances at least one Tuckman stage within 3-6 months of coaching
• Psychological safety score on Edmondson scale exceeds 4.0/5.0

Tool Reference

velocity_analyzer.py

Analyzes sprint velocity data with trend detection, Monte Carlo forecasting, and anomaly identification.

sprint_health_scorer.py

Scores sprint health across 6 weighted dimensions with composite grading and recommendations.

retrospective_analyzer.py

Processes retrospective data to track action item completion, identify recurring themes, and assess team maturity.

sprint_capacity_calculator.py

Calculates sprint capacity accounting for ceremony overhead, PTO, allocation percentages, and focus factor.

Red Flags: Scrum Master

Common ways this skill's output goes wrong -- concrete examples, why they're bad, and how to fix them.

How to use this document

Scan every sprint planning output, velocity report, retrospective summary, and team-health dashboard before sharing. Each red flag has bad and good quoted examples.

---

Red Flag 1: Velocity-as-Target

Symptom. "Our velocity must hit 38 SP every sprint." Team is rewarded / punished against the number. Why it's bad. Velocity is a capacity signal, not a productivity target. When you target it, Goodhart's Law applies: engineers inflate story points (each story silently grows from 3 to 5), and the number rises while throughput is unchanged. Then the team commits to more than it can deliver, slips, and the trust collapses. Bad example:

"Engineering manager OKR: 'Increase team velocity from 32 to 40 SP/sprint by Q3.' Bonuses tied to delivery vs that target."

Good example:

"Velocity is used only as a planning input: 'last 4 sprints averaged 28-34 SP with 80% confidence; therefore commit ~28 SP this sprint.' Performance is measured by outcomes (OKRs, customer metrics), not velocity. Documented in the team charter."

How to catch it. Any management OKR or bonus tied to velocity = remove. See jira-expert/references/red-flags.md Red Flag 6.

---

Red Flag 2: Retro Action-Item Rot

Symptom. Every retro produces 4-6 action items. Next retro: 80% of last sprint's items are not done, and the team re-discusses the same problems. Why it's bad. Action items that do not get executed teach the team that retros do not matter. Participation drops; the retro becomes a ritual. The original problems recur sprint after sprint. Bad example:

"Retro 5: 4 action items. Retro 6 (next sprint): 3 of 4 still open; 2 re-added as 'this time we mean it'."

Good example:

"Retro process: max 2 action items per retro, each with explicit Owner + Due Date (within sprint). Sprint Review includes 1-min review of retro action-item progress. Items that slip get a root-cause analysis, not a re-add."

How to catch it. Same problem appears in > 2 consecutive retros = root-cause it instead of re-adding.

---

Red Flag 3: Daily Standup as Status Report to the Manager

Symptom. Standup format: each person reports yesterday/today/blockers, addressed to the engineering manager who silently takes notes. Why it's bad. Standup is a coordination meeting, not a status meeting. Reporting to the manager makes it political; engineers censor blockers and the meeting becomes performative. The team loses its coordination signal. Bad example:

"Standup: 15 engineers go around the room, each says 3 lines to the manager. Manager interrupts twice with follow-up questions. Total time: 28 min."

Good example:

"Standup is 'walk the board' format: focus on tickets in progress, not on people. Discuss what is blocked, what is at risk of slipping, what needs help. Manager attends optionally; team leads coordination. < 12 min."

How to catch it. Standup format 'go around the room' + > 15 min = restructure to walk-the-board.

---

Red Flag 4: Sprint Goal Missing or Generic

Symptom. Sprint goal: "Complete the sprint backlog." (Or absent entirely.) Why it's bad. Sprint goal is the team's commitment to a coherent outcome. Without it, the sprint becomes a basket of unrelated tickets with no narrative. The team cannot trade off in-sprint scope coherently, and the sprint review has no story to tell. Bad example:

"Sprint 23 goal: 'Finish all 14 tickets.'"

Good example:

"Sprint 23 goal: 'A new user can sign up, complete onboarding, and see their first useful dashboard in < 5 min, on staging. Other work (refactors, bug fixes) is in scope only if it does not block this goal.'"

How to catch it. Sprint goal mentions ticket count, not customer-visible outcome = rewrite.

---

Red Flag 5: Capacity Ignores PTO / On-Call / Interviews

Symptom. "Team has 8 engineers x 2 weeks = 16 person-weeks capacity." Ignoring PTO (1), on-call (2), interview load (1). Why it's bad. Over-estimating capacity means over-committing, which means slipping, which destroys trust. The team chronically misses sprint commitments; planning becomes meaningless. Bad example:

"Capacity: 8 engineers x 10 working days = 80 IC-days. Committed: 80 IC-days of work."

Good example:

"Capacity model:

- 8 engineers x 10 working days = 80 IC-days gross.

- Subtract: PTO (4 days), on-call rotation (6 days), interview load (3 days), required maintenance (8 days) = 21 days.

- Net: 59 IC-days.

- Commit at 80% confidence: ~47 IC-days = ~22 SP at calibrated 2.1 IC-days / SP."

How to catch it. Capacity calc does not subtract PTO / on-call / interviews = redo.

---

Red Flag 6: Definition of Done Drift

Symptom. Team's DoD says "tested + reviewed + deployed". In reality, half the sprints close with tickets marked Done but no tests, or with deploys pending. Why it's bad. When DoD drifts, "Done" stops meaning anything. Bugs leak to production; reviewers find regressions weeks later; rework destroys velocity. The honest velocity is much lower than reported. Bad example:

"DoD: tested, reviewed, deployed. Actual: 60% of closed tickets have no tests; 40% have not deployed."

Good example:

"DoD is enforced by automation: tickets cannot move to Done unless (1) PR is merged, (2) CI passed including the test runner, (3) the deployment status check is green. Manual checks: code-review approval, design review where relevant. Drift surfaces in sprint review."

How to catch it. Sample 10 closed tickets from last sprint; check each against DoD. > 20% gap = enforce via automation.

---

Red Flag 7: Estimation by the Loudest Voice

Symptom. Story points are set by whoever speaks first in planning poker, not by the median of the group. Why it's bad. Loudest-voice estimation drifts toward optimism (the optimist speaks first) or pessimism (the senior engineer speaks first). The team's collective wisdom is lost; estimates become unreliable. Bad example:

"Planning poker: 'I think this is a 3.' Team: 'OK, 3.' (No reveal; no discussion of divergent estimates.)"

Good example:

"Planning poker with simultaneous reveal: cards down, all reveal together. If estimates diverge by > 2 points, low + high voices each explain reasoning; re-vote. Final = median (not average; outliers ignored)."

How to catch it. Watch a planning poker session. If estimates converge without reveal-then-discuss, restructure.

---

Red Flag 8: Retro Without Data

Symptom. Retro is "how did people feel this sprint?". No metrics on cycle time, throughput, escaped bugs, sprint goal completion. Why it's bad. Feelings-only retros surface the loudest concerns but miss systematic patterns (cycle-time creeping up, escaped-bug rate doubling, planning accuracy declining). The team treats anecdotes as systemic. Bad example:

"Retro: 'I felt overwhelmed.' 'I felt the work was fragmented.' 'I felt good.' Action: 'try to focus more.'"

Good example:

"Retro starts with a 5-minute data review: sprint goal completion, throughput, cycle time, escaped-bug count, capacity vs committed vs done. Discussion grounded in patterns. Action items address what the data shows, not just what was felt."

How to catch it. Retro has no data slide = use retrospective_analyzer.py to generate one.

---

Red Flag 9: Scrum Master Owns the Backlog

Symptom. Scrum master grooms the backlog, prioritizes items, writes acceptance criteria. Why it's bad. Scrum master is a facilitator, not the product owner. Owning the backlog blurs roles and short-circuits the PM. The team trains around the SM's preferences, not the customer's needs. Bad example:

"Scrum master ranks the backlog in collaboration with engineering. PM is not involved in refinement."

Good example:

"Scrum master facilitates the refinement ritual but does not own ranking. PM (or PO) owns: priority order, acceptance criteria, the WHY in WWAS. Engineering owns: technical approach, estimation, the HOW. Scrum master owns: the process working smoothly."

How to catch it. PM is absent from refinement = restore role boundary.

---

Red Flag 10: Sprint Review Without the Customer Outcome

Symptom. Sprint review = demo of what shipped. Audience: engineering manager. No discussion of whether the sprint goal was met, no customer / stakeholder present. Why it's bad. Sprint review is meant to inspect the increment with stakeholders -- to validate that what shipped achieves the outcome. A demo without outcome discussion is a show-and-tell with no learning loop. Bad example:

"Sprint review: 30 min of demos. Engineering manager nods. No discussion of sprint goal."

Good example:

"Sprint review structure: (1) restate sprint goal; (2) demo against the goal; (3) discuss whether the goal was met (with the metric, where measurable); (4) stakeholder Q&A; (5) implications for next sprint. Audience includes PM, design, and ideally a customer-success rep."

How to catch it. Sprint review attendance = engineering only = invite stakeholders + restructure.

---

Red Flag Quick Reference

Related Reading

• SKILL.md -- scrum master role + analytics
• scripts/sprint_capacity_calculator.py --help -- capacity model
• scripts/velocity_analyzer.py --help -- velocity as a planning signal
• scripts/sprint_health_scorer.py --help -- 6-dimension sprint health
• scripts/retrospective_analyzer.py --help -- data-driven retro
• Sibling skill: sprint-retrospective/ -- the retro skill itself
• Sibling skill: agile-coach/ -- broader agile-transformation patterns
• Sibling skill: jira-expert/ -- the tooling for tracking

Sprint Retrospective Formats

Start/Stop/Continue

Best for: Teams new to retrospectives, quick format Duration: 45-60 minutes

Structure

Create three columns:

• Start: What should we begin doing?
• Stop: What should we stop doing?
• Continue: What's working well that we should keep doing?

Process

1. Team silently adds items to each column (10 min) 2. Group similar items (5 min) 3. Discuss each category, vote on top items (20 min) 4. Select 2-3 actions (10 min)

Example Output

Start:

• Pairing on complex stories
• Code reviews within 4 hours

Stop:

• Taking on work mid-sprint
• Skipping acceptance criteria

Continue:

• Daily standups at 9:30am
• Demo prep on Thursday

---

Glad/Sad/Mad

Best for: Emotional check-in, team morale assessment Duration: 60-75 minutes

Structure

Create three areas:

• Glad: What made you happy this sprint?
• Sad: What disappointed you?
• Mad: What frustrated you?

Process

1. Silent brainstorming (10 min) 2. Share items, one person at a time (15 min) 3. Group themes (5 min) 4. Discuss top items from each category (20 min) 5. Identify action items (10 min)

Example Output

Glad:

• Shipped feature X on time
• Great collaboration with design team
• New deployment process worked well

Sad:

• Lost time to production bugs
• Didn't finish all committed work
• Documentation fell behind

Mad:

• Environment was down 2 days
• Requirements changed mid-sprint
• Still waiting on API key from vendor

Facilitation Tips

• Acknowledge emotions, don't dismiss
• Focus on what we can control
• Convert frustrations into actions

---

4Ls (Liked, Learned, Lacked, Longed For)

Best for: Deeper reflection, learning focus Duration: 60-90 minutes

Structure

• Liked: What went well? What did we enjoy?
• Learned: What new insights did we gain?
• Lacked: What was missing? What did we need?
• Longed For: What do we wish we had?

Process

1. Individual reflection (10 min) 2. Round-robin sharing (20 min) 3. Group similar items (10 min) 4. Deep dive on top items (20 min) 5. Action planning (15 min)

Example Output

Liked:

• Pair programming sessions
• Clear acceptance criteria
• Product Owner availability

Learned:

• New testing framework capabilities
• How to better estimate stories
• Importance of architectural review

Lacked:

• Automated deployment
• Clear API documentation
• Sufficient testing time

Longed For:

• Better development environments
• More design time upfront
• Dedicated QA support

---

Sailboat

Best for: Visual teams, identifying headwinds and tailwinds Duration: 60-90 minutes

Structure

Draw a sailboat with:

• Wind (propellers): What's helping us go faster?
• Anchors: What's slowing us down?
• Rocks (hazards): What risks are ahead?
• Island (goal): Where are we headed?

Process

1. Explain metaphor (5 min) 2. Team adds sticky notes to each area (15 min) 3. Group and discuss each area (30 min) 4. Prioritize anchors to remove (10 min) 5. Create action plan (15 min)

Example Output

Wind:

• Strong team collaboration
• Clear product vision
• Good tooling

Anchors:

• Slow CI/CD pipeline
• Too many meetings
• Technical debt

Rocks:

• Upcoming dependency on Team B
• Key person on vacation next sprint
• Infrastructure migration

Island:

• Launch v2.0 by end of quarter
• Improve system stability
• Reduce production bugs by 50%

---

Timeline

Best for: Detailed sprint review, identifying patterns Duration: 75-90 minutes

Structure

Create a timeline of the sprint on a whiteboard:

• Days of the sprint across the top
• Events, milestones, feelings plotted on timeline

Process

1. Draw sprint timeline (5 min) 2. Team adds events chronologically (15 min) 3. Add emotion indicators (happy/sad/stressed) (10 min) 4. Identify patterns and themes (20 min) 5. Discuss high/low points (20 min) 6. Extract learnings and actions (15 min)

Example Timeline

Day 1: Sprint planning, feeling optimistic 😊
Day 3: Production bug discovered, stressed 😰
Day 5: Bug fixed, relieved 😌
Day 7: Design feedback changed scope, frustrated 😠
Day 9: Great pairing session on new feature 😊
Day 10: Demo went really well! 🎉

Facilitation Tips

• Focus on objective events first, emotions second
• Look for correlations between events and feelings
• Identify early warning signs
• Celebrate wins

---

Starfish

Best for: More granular feedback than Start/Stop/Continue Duration: 60-90 minutes

Structure

Five categories:

• Keep Doing: What's working, don't change
• Less Of: What should we reduce?
• More Of: What should we increase?
• Stop Doing: What should we eliminate?
• Start Doing: What new practices should we try?

Process

1. Explain each category (5 min) 2. Silent brainstorming (15 min) 3. Share and group items (15 min) 4. Discuss each category (25 min) 5. Vote on top actions (10 min) 6. Create action plan (15 min)

Example Output

Keep Doing:

• Pairing on complex stories
• Demo every Friday

Less Of:

• Context switching
• Unplanned work

More Of:

• Automated testing
• Design upfront

Stop Doing:

• Skipping code reviews
• Working weekends

Start Doing:

• Mob programming for knowledge sharing
• Weekly architecture discussions

---

Speed Dating

Best for: Large teams, fresh perspectives Duration: 60 minutes

Structure

• Pair up team members who don't usually work together
• Rotate pairs every 10 minutes
• Discuss sprint from different perspectives

Process

1. Create pairs (2 min) 2. Round 1: "What went well?" (10 min) 3. Rotate pairs (2 min) 4. Round 2: "What could improve?" (10 min) 5. Rotate pairs (2 min) 6. Round 3: "What should we try?" (10 min) 7. Full group synthesis (15 min) 8. Action planning (10 min)

Facilitation Tips

• Ensure quiet voices are heard
• Mix up pairs intentionally
• Capture themes as they emerge
• Focus on shared themes in synthesis

---

Three Little Pigs

Best for: Architecture and technical decisions Duration: 60-75 minutes

Structure

Based on the story:

• Straw House: What's fragile? What will blow down?
• Stick House: What's okay but could be better?
• Brick House: What's solid and will last?

Process

1. Explain metaphor (5 min) 2. Team identifies items for each house (15 min) 3. Group and discuss (20 min) 4. Prioritize straw house items to fix (10 min) 5. Create action plan (15 min)

Example Output

Straw House (fragile):

• Manual deployment process
• No automated tests for API
• Undocumented code

Stick House (needs improvement):

• Test coverage at 60%
• Some documentation exists
• Partially automated builds

Brick House (solid):

• Strong CI/CD for frontend
• Well-tested core modules
• Clear architecture docs

---

Facilitation Best Practices

Before Retrospective

• Review previous action items
• Gather sprint metrics
• Choose format based on team needs
• Prepare collaboration space

During Retrospective

• Set the stage: Create safe environment
• Prime directive: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
• Timebox discussions: Keep energy high
• Focus on actions: Not just talk
• Limit action items: 1-3 max for next sprint
• Get specific: Vague actions don't happen

After Retrospective

• Document immediately in Confluence
• Create Jira tickets for actions
• Assign owners and due dates
• Track completion
• Start next retro by reviewing these

Red Flags

• Same issues every retro → Need deeper intervention
• No action items → Team not engaged
• Blame game → Not safe environment
• No follow-through → Actions not valued
• Facilitator talks more than team → Not facilitating

Rotation Strategy

• Vary formats every 2-3 sprints
• Let team choose occasionally
• Match format to team mood
• Try new format when stuck

Sprint Planning Guide: Comprehensive Reference for Scrum Masters

Table of Contents

• Overview
• Pre-Planning Checklist
• Sprint Goal Setting
• Capacity Planning Methodology
• Story Selection Criteria
• Commitment vs Forecast
• Sprint Planning Meeting Facilitation
• Common Anti-Patterns
• Tool Integration

---

Overview

Sprint planning is the ceremony that sets the direction for each sprint. Effective sprint planning requires preparation, data-driven capacity analysis, clear goal setting, and collaborative story selection. This guide provides a structured approach for Scrum Masters to facilitate productive sprint planning sessions.

Key Principles

1. Data-Informed Decisions: Use historical velocity and capacity data, not gut feel 2. Team Ownership: The team commits to the sprint backlog, not the Scrum Master or Product Owner 3. Goal-Driven Selection: Every story should map to the sprint goal 4. Realistic Capacity: Account for ceremony overhead, PTO, and focus factor 5. Preparation Is Everything: 80% of sprint planning success happens before the meeting

---

Pre-Planning Checklist

Complete these steps before the sprint planning meeting begins.

Velocity Analysis (2-3 days before planning)

• [ ] Pull velocity data for the last 3-6 sprints
• [ ] Calculate rolling 3-sprint and 5-sprint averages
• [ ] Note any anomalies or outliers and their causes
• [ ] Identify velocity trend (improving, stable, or declining)
• [ ] Run velocity_analyzer.py on recent sprint data for statistical analysis
• [ ] Review the volatility level (low, moderate, high)

Backlog Readiness (2-3 days before planning)

• [ ] Confirm top 2x sprint capacity worth of stories meet Definition of Ready
• [ ] Verify story points are assigned to candidate stories
• [ ] Check for missing acceptance criteria
• [ ] Identify and document inter-story dependencies
• [ ] Ensure Product Owner has prioritized the backlog
• [ ] Confirm technical spikes or research items are resolved

Capacity Check (1 day before planning)

• [ ] Collect PTO and out-of-office plans for the sprint
• [ ] Confirm team member allocation percentages
• [ ] Note any team composition changes (new members, departures)
• [ ] Run sprint_capacity_calculator.py with team data
• [ ] Calculate available hours with ceremony overhead deducted
• [ ] Apply 80-85% focus factor for realistic planning

Stakeholder Alignment (1-2 days before planning)

• [ ] Product Owner has reviewed and refined the sprint goal
• [ ] Known external dependencies are identified
• [ ] Release commitments and deadlines are visible
• [ ] Cross-team coordination items are flagged

---

Sprint Goal Setting

SMART Sprint Goals

Every sprint should have a single, clear goal that follows the SMART format:

Sprint Goal Templates

Feature-Focused:

"By the end of this sprint, users will be able to [capability], enabling [business outcome]."

Technical-Focused:

"Reduce [technical metric] by [target]% to improve [user-facing outcome]."

Discovery-Focused:

"Validate [hypothesis] through [method] to inform [decision]."

Debt-Focused:

"Resolve [specific debt items] to unblock [future capability] and reduce [risk/maintenance cost]."

Alignment with Product Goals

• Sprint goal should trace to a product roadmap item or OKR
• The Product Owner should explain WHY this goal matters now
• Team should understand the business context behind the goal
• Sprint goal is the tiebreaker when prioritizing work during the sprint

---

Capacity Planning Methodology

Step 1: Calculate Gross Available Hours

For each team member:

Gross Hours = (Available Days - PTO Days) x Hours Per Day x (Allocation% / 100)

Step 2: Deduct Ceremony Overhead

Standard ceremony overhead per team member per sprint (10-day sprint):

Net Hours = Gross Hours - Ceremony Hours

Step 3: Apply Focus Factor

The focus factor accounts for interruptions, context switching, ad-hoc meetings, email, and general productivity loss:

Realistic Capacity = Net Hours x Focus Factor

Step 4: Convert to Story Points (Optional)

If the team uses story points and has historical velocity:

Estimated Points = Historical Velocity x (Current Capacity / Typical Capacity)

Use sprint_capacity_calculator.py to automate this calculation:

python scripts/sprint_capacity_calculator.py team_data.json --format text

Capacity Planning Example

With 80% focus factor: 108.0h realistic capacity

---

Story Selection Criteria

Definition of Ready Checklist

A story must meet ALL of these criteria before it can be pulled into a sprint:

• [ ] User story or job story format is complete
• [ ] Acceptance criteria are written in Given/When/Then format
• [ ] Story is sized (story points assigned)
• [ ] Story is small enough to complete within one sprint
• [ ] Dependencies are identified and resolved (or plan exists)
• [ ] UX designs or wireframes are available (if applicable)
• [ ] Technical approach is understood by at least 2 team members
• [ ] Product Owner can answer clarifying questions
• [ ] Story is prioritized in the backlog

Dependency Assessment

For each candidate story, evaluate:

Risk Evaluation

Rate each story on these dimensions before inclusion:

1. Complexity: Is the technical approach well understood? 2. Uncertainty: How much discovery is still needed? 3. Size: Is this the right size or should it be split? 4. Dependencies: Are all inputs available? 5. Testing: Is the test strategy clear?

Stories with high risk scores should be:

• Placed early in the sprint (fail fast)
• Paired with a buffer or contingency plan
• Split into smaller, lower-risk pieces

---

Commitment vs Forecast

The Shift from Commitment to Forecast

Modern Scrum practice has moved from "commitment" (a promise to deliver) to "forecast" (a best estimate of what can be done). Understanding this distinction is critical.

When to Use Each

Use commitment language when:

• Release deadlines are fixed and non-negotiable
• External stakeholders need firm delivery dates
• The team has high velocity stability (low volatility)

Use forecast language when:

• Sprint goal is clear but exact scope may flex
• Team is still stabilizing or has high volatility
• Stories have significant uncertainty
• You want to encourage healthy risk-taking

Practical Application

Present the sprint plan as:

"Based on our capacity of X hours and historical velocity of Y points, we forecast completing these stories. Our sprint goal is [GOAL]. Stories A, B, and C directly support the goal. Stories D and E are stretch goals if capacity allows."

---

Sprint Planning Meeting Facilitation

Meeting Setup

• Duration: 2 hours for a 2-week sprint (1 hour for 1-week sprint)
• Attendees: Scrum Master, Product Owner, Development Team
• Pre-work: All items from Pre-Planning Checklist completed
• Materials: Capacity report, prioritized backlog, sprint board

Part 1: The WHAT (45-60 minutes)

Purpose: Establish the sprint goal and select candidate stories.

Facilitation Flow:

1. Product Owner presents sprint goal (5 min)

• Business context and why this goal matters now
• Alignment with product roadmap and OKRs
• Success criteria for the sprint

2. Scrum Master presents capacity (5 min)

• Team availability and PTO
• Ceremony overhead deductions
• Focus-adjusted capacity in hours and estimated points
• Reference sprint_capacity_calculator.py output

3. Velocity context (5 min)

• Last 3-sprint rolling average
• Trend direction and confidence
• Reference velocity_analyzer.py output

4. Product Owner walks through candidate stories (20-30 min)

• Present stories in priority order
• Team asks clarifying questions
• Confirm each story meets Definition of Ready
• Flag dependencies and risks

5. Team selects stories for the sprint (10-15 min)

• Pull stories up to forecast capacity
• Confirm sprint goal alignment
• Identify stretch goals (clearly labeled)
• Team verbally confirms the forecast

Part 2: The HOW (45-60 minutes)

Purpose: Break stories into tasks and create a plan for delivery.

Facilitation Flow:

1. Task breakdown (30-40 min)

• For each story, identify implementation tasks
• Estimate task durations (optional, in hours)
• Identify task owners or pairs
• Note technical dependencies between tasks

2. Sequencing and scheduling (10 min)

• Identify which stories to start first
• Highlight critical path items
• Plan for early validation of risky stories

3. Final capacity check (5 min)

• Verify total task estimates fit within capacity
• Adjust scope if over-committed
• Confirm the sprint backlog

4. Sprint plan confirmation (5 min)

• Scrum Master reads back the sprint goal
• Team confirms the forecast
• Note any open questions or risks to monitor

Facilitation Tips

• Timebox aggressively: Use a visible timer for each section
• Redirect deep dives: "Great topic, let's take that offline after planning"
• Ensure everyone speaks: Directly ask quieter team members for input
• Capture parking lot items: Keep a visible list of deferred discussions
• Energy management: Take a 5-minute break between Part 1 and Part 2
• Make it visual: Update the sprint board in real-time during planning

---

Common Anti-Patterns

1. Over-Commitment

Symptom: Team consistently carries over stories sprint after sprint. Root Cause: Planning to velocity ceiling instead of average; ignoring capacity changes. Fix: Use 80% focus factor, plan to rolling average velocity, track carry-over rate.

2. No Sprint Goal

Symptom: Sprint is just a random collection of stories. Root Cause: Product Owner not engaged in planning; no strategic direction. Fix: Require a sprint goal before story selection begins; tie stories to the goal.

3. Ignoring Velocity Data

Symptom: Team plans "by feel" and velocity is unpredictable. Root Cause: Lack of data collection or distrust of metrics. Fix: Run velocity_analyzer.py regularly; use data to inform, not dictate.

4. Stories Not Ready

Symptom: Planning takes 3+ hours due to clarification questions. Root Cause: Insufficient backlog refinement; Definition of Ready not enforced. Fix: Enforce DoR check before planning; invest in refinement sessions.

5. Scope Creep During Sprint

Symptom: Stories added mid-sprint, original goal abandoned. Root Cause: Weak sprint protection; stakeholder pressure; unclear sprint goal. Fix: Scrum Master shields the team; any addition requires equal removal.

6. Skipping Part 2 (The How)

Symptom: Team starts sprint without a plan; stories sit untouched for days. Root Cause: Time pressure; belief that Part 2 is optional. Fix: Protect Part 2 time; even 30 minutes of task breakdown reduces surprises.

7. One Person Dominates Planning

Symptom: Tech lead or senior developer makes all decisions. Root Cause: Low psychological safety; habit; perceived efficiency. Fix: Use round-robin for story discussion; explicitly ask for input from all.

8. Padding with Stretch Goals

Symptom: Team always pulls in "stretch goals" as buffer items. Root Cause: Stretch goals used to mask over-commitment or under-commitment. Fix: Clearly separate committed forecast from stretch items; track both.

---

Tool Integration

velocity_analyzer.py

Use before sprint planning to understand velocity trends:

# Analyze recent velocity data
python scripts/velocity_analyzer.py sprint_data.json --format text

# Get JSON output for dashboards
python scripts/velocity_analyzer.py sprint_data.json --format json

Key outputs for sprint planning:

• Rolling 3-sprint and 5-sprint velocity averages
• Trend direction and confidence level
• Volatility assessment (low/moderate/high)
• Anomaly detection for recent sprints
• Monte Carlo forecast for upcoming sprints

sprint_capacity_calculator.py

Use to calculate team capacity for the upcoming sprint:

# Calculate capacity from team data
python scripts/sprint_capacity_calculator.py team_data.json --format text

# Demo mode to see expected output
python scripts/sprint_capacity_calculator.py --demo

# JSON output for integration
python scripts/sprint_capacity_calculator.py team_data.json --format json

Input JSON format:

{
  "sprint_length_days": 10,
  "historical_velocity": 42,
  "team_members": [
    {
      "name": "Alice",
      "role": "Developer",
      "available_days": 10,
      "hours_per_day": 6,
      "allocation_percent": 100,
      "planned_pto_days": 0
    }
  ]
}

Key outputs for sprint planning:

• Per-member capacity breakdown
• Ceremony overhead calculation
• Focus-adjusted capacity (80% and 85%)
• Story point estimates based on historical velocity
• Warnings for low allocation or high PTO

Combined Workflow

1. Run velocity_analyzer.py to understand team velocity trends 2. Prepare team data JSON with PTO and allocation for the sprint 3. Run sprint_capacity_calculator.py to get capacity numbers 4. Use both outputs to inform the sprint planning discussion 5. Document the sprint plan using assets/sprint_plan_template.md

---

Quick Reference Card

Sprint Planning Checklist (Day-Of)

BEFORE THE MEETING:
[ ] Velocity report generated (velocity_analyzer.py)
[ ] Capacity calculated (sprint_capacity_calculator.py)
[ ] Backlog groomed; top stories meet Definition of Ready
[ ] Product Owner has sprint goal prepared
[ ] Sprint board is clean (previous sprint closed)

DURING THE MEETING:
[ ] Sprint goal presented and understood by team
[ ] Capacity shared (hours and estimated points)
[ ] Stories selected up to forecast capacity
[ ] Stretch goals clearly labeled
[ ] Tasks broken down for each story
[ ] Sprint plan confirmed by the team

AFTER THE MEETING:
[ ] Sprint board updated with committed stories
[ ] Sprint goal posted visibly
[ ] Sprint plan template filled out
[ ] Calendar blocked for ceremonies
[ ] Stakeholders notified of sprint scope

---

This guide provides a comprehensive framework for sprint planning. Adapt the practices to your team's maturity level, sprint length, and organizational context. The goal is continuous improvement in planning effectiveness, measured by commitment reliability and sprint goal achievement.

Scrum Master Workflow & Operations

Read this when running the end-to-end Scrum Master workflow (assess → health → forecast → capacity → retro → coach), wiring up the tools, or preparing the JSON input schema.

Workflow

1. Assess Current State

The agent collects sprint data and establishes baselines:

python scripts/velocity_analyzer.py sprint_data.json --format json > velocity_baseline.json
python scripts/sprint_health_scorer.py sprint_data.json --format text
python scripts/retrospective_analyzer.py sprint_data.json --format text

Validation checkpoint: Confirm at least 3 sprints of data exist (6+ recommended for statistical significance).

2. Analyze Sprint Health

The agent scores the team across 6 weighted dimensions:

Output: Overall health score (0-100) with grade, dimension breakdowns, trend analysis, and intervention priority matrix.

3. Forecast Velocity

The agent runs Monte Carlo simulation on historical velocity data:

python scripts/velocity_analyzer.py sprint_data.json --format text

Output includes:

• Rolling averages (3, 5, 8 sprint windows)
• Trend detection via linear regression
• Volatility classification (coefficient of variation)
• Anomaly detection (outliers beyond 2 sigma)
• 6-sprint forecast with 50%, 70%, 85%, 95% confidence intervals

Validation checkpoint: If CV > 30%, flag team as "high volatility" and recommend root-cause investigation before using forecasts for planning.

4. Plan Sprint Capacity

python scripts/sprint_capacity_calculator.py team_data.json --format text

The calculator accounts for:

• Per-member availability (PTO, allocation percentage)
• Ceremony overhead: planning (2h) + daily standup (15min/day) + review (1h) + retro (1h) + refinement (1h)
• Focus factor (80% realistic, 85% optimistic)
• Story point estimates (conservative, realistic, optimistic) from historical velocity

Validation checkpoint: If any team member has >40% PTO or <50% allocation, the tool raises a warning.

5. Facilitate Retrospective

The agent uses retrospective analyzer insights to guide discussion:

python scripts/retrospective_analyzer.py sprint_data.json --format text

Analysis includes:

• Action item completion rates by priority and owner
• Recurring theme identification with persistence scoring
• Sentiment trend tracking (positive/negative)
• Team maturity assessment (forming/storming/norming/performing)

Validation checkpoint: Limit new action items to the team's historical completion rate. If the team completes 50% of action items, cap at 2-3 new items per retro.

6. Coach Team Development

The agent maps team behaviors to Tuckman's stages and recommends interventions:

Psychological safety assessment uses Edmondson's 7-point scale. Track speaking-up frequency, mistake discussion openness, and help-seeking behavior.

Example: Sprint Planning with Forecast

Given 6 sprints of velocity data [18, 22, 20, 19, 23, 21]:

$ python scripts/velocity_analyzer.py sprint_data.json --format text

Velocity Analysis
=================
Average: 20.5 points
Trend: Stable (slope: +0.3/sprint)
Volatility: Low (CV: 8.7%)

Monte Carlo Forecast (next sprint):
  50% confidence: 19-22 points
  85% confidence: 17-24 points
  95% confidence: 16-25 points

Recommendation: Commit to 19-20 points for reliable delivery.
Use 22 points only if team has no PTO and no known blockers.

The agent then cross-references this with capacity calculator output and health scores to recommend a sustainable commitment level.

Input Schema

All tools accept JSON following assets/sample_sprint_data.json:

{
  "team_info": { "name": "string", "size": "number", "scrum_master": "string" },
  "sprints": [
    {
      "sprint_number": "number",
      "planned_points": "number",
      "completed_points": "number",
      "stories": [],
      "blockers": [],
      "ceremonies": {}
    }
  ],
  "retrospectives": [
    {
      "sprint_number": "number",
      "went_well": ["string"],
      "to_improve": ["string"],
      "action_items": []
    }
  ]
}