/retrospective-analyzer

Retrospective Analyzer

Analyze team retrospectives for insights

Instructions

1. **Retrospective Setup**

• Identify sprint to analyze (default: most recent)
• Check Linear MCP connection for sprint data
• Define retrospective format preference
• Set analysis time range

2. **Sprint Data Collection**

Quantitative Metrics

From Linear/Project Management:
- Planned vs completed story points
- Sprint velocity and capacity
- Cycle time and lead time
- Escaped defects count
- Unplanned work percentage

From Git/GitHub:
- Commit frequency and distribution
- PR merge time statistics  
- Code review turnaround
- Build success rate
- Deployment frequency

Qualitative Data Sources

1. PR review comments sentiment
2. Commit message patterns
3. Slack conversations (if available)
4. Previous retrospective action items
5. Support ticket trends

3. **Automated Analysis**

Sprint Performance Analysis

# Sprint [Name] Retrospective Analysis

## Sprint Overview
- Duration: [Start] to [End]
- Team Size: [Number] members
- Sprint Goal: [Description]
- Goal Achievement: [Yes/Partial/No]

## Key Metrics Summary

### Delivery Metrics
| Metric | Target | Actual | Variance |
|--------|--------|--------|----------|
| Velocity | [X] pts | [Y] pts | [+/-Z]% |
| Completion Rate | 90% | [X]% | [+/-Y]% |
| Defect Rate | <5% | [X]% | [+/-Y]% |
| Unplanned Work | <20% | [X]% | [+/-Y]% |

### Process Metrics
| Metric | This Sprint | Previous | Trend |
|--------|-------------|----------|-------|
| Avg PR Review Time | [X] hrs | [Y] hrs | [↑/↓] |
| Avg Cycle Time | [X] days | [Y] days | [↑/↓] |
| CI/CD Success Rate | [X]% | [Y]% | [↑/↓] |
| Team Happiness | [X]/5 | [Y]/5 | [↑/↓] |

Pattern Recognition

## Identified Patterns

### Positive Patterns 🟢
1. **Improved Code Review Speed**
   - Average review time decreased by 30%
   - Correlation with new review guidelines
   - Recommendation: Document and maintain process

2. **Consistent Daily Progress**
   - Even commit distribution throughout sprint
   - No last-minute rush
   - Indicates good sprint planning

### Concerning Patterns 🔴
1. **Monday Deploy Failures**
   - 60% of failed deployments on Mondays
   - Possible cause: Weekend changes not tested
   - Action: Implement Monday morning checks

2. **Increasing Scope Creep**
   - 35% unplanned work (up from 20%)
   - Source: Urgent customer requests
   - Action: Review sprint commitment process

4. **Interactive Retrospective Facilitation**

Pre-Retrospective Report

# Pre-Retrospective Insights

## Data-Driven Discussion Topics

### 1. What Went Well 
Based on the data, these areas showed improvement:
- ✅ Code review efficiency (+30%)
- ✅ Test coverage increase (+5%)
- ✅ Zero critical bugs in production
- ✅ All team members contributed evenly

**Suggested Discussion Questions:**
- What specific changes led to faster reviews?
- How can we maintain zero critical bugs?
- What made work distribution successful?

### 2. What Didn't Go Well
Data indicates challenges in these areas:
- ❌ Sprint velocity miss (-15%)
- ❌ High unplanned work (35%)
- ❌ 3 rollbacks required
- ❌ Team overtime increased

**Suggested Discussion Questions:**
- What caused the velocity miss?
- How can we better handle unplanned work?
- What led to the rollbacks?

### 3. Action Items from Data
Recommended improvements based on patterns:
1. Implement feature flags for safer deployments
2. Create unplanned work budget in sprint planning
3. Add integration tests for [problem area]
4. Schedule mid-sprint check-ins

Live Retrospective Support

During the retrospective, I can help with:

1. **Fact Checking**: 
   "Actually, our velocity was 45 points, not 50"

2. **Pattern Context**:
   "This is the 3rd sprint with Monday deploy issues"

3. **Historical Comparison**:
   "Last time we had similar issues, we tried X"

4. **Action Item Tracking**:
   "From last retro, we completed 4/6 action items"

5. **Retrospective Output Formats**

Standard Retrospective Summary

# Sprint [X] Retrospective Summary

## Participants
[List of attendees]

## What Went Well
- [Categorized list with vote counts]
- Supporting data: [Metrics]

## What Didn't Go Well  
- [Categorized list with vote counts]
- Root cause analysis: [Details]

## Action Items
| Action | Owner | Due Date | Success Criteria |
|--------|-------|----------|------------------|
| [Action 1] | [Name] | [Date] | [Measurable outcome] |
| [Action 2] | [Name] | [Date] | [Measurable outcome] |

## Experiments for Next Sprint
1. [Experiment description]
   - Hypothesis: [What we expect]
   - Measurement: [How we'll know]
   - Review date: [When to assess]

## Team Health Pulse
- Energy Level: [Rating]/5
- Clarity: [Rating]/5
- Confidence: [Rating]/5
- Key Quote: "[Notable team sentiment]"

Trend Analysis Report

# Retrospective Trends Analysis

## Recurring Themes (Last 5 Sprints)

### Persistent Challenges
1. **Deployment Issues** (4/5 sprints)
   - Root cause still unresolved
   - Recommended escalation

2. **Estimation Accuracy** (5/5 sprints)
   - Consistent 20% overrun
   - Needs systematic approach

### Improving Areas
1. **Communication** (Improving for 3 sprints)
2. **Code Quality** (Steady improvement)

### Success Patterns
1. **Pair Programming** (Mentioned positively 5/5)
2. **Daily Standups** (Effective format found)

6. **Action Item Generation**

Smart Action Items

Based on retrospective discussion, here are SMART action items:

1. **Reduce Deploy Failures**
   - Specific: Implement smoke tests for Monday deploys
   - Measurable: <5% failure rate
   - Assignable: DevOps team
   - Relevant: Addresses 60% of failures
   - Time-bound: By next sprint

2. **Improve Estimation**
   - Specific: Use planning poker for all stories
   - Measurable: <20% variance from estimates
   - Assignable: Scrum Master facilitates
   - Relevant: Addresses velocity m