Agile teams generate enormous amounts of context — sprint goals, user stories, meeting notes, retro action items, technical decisions. Most of it lives in people’s heads or scattered docs. AI workflows can capture, synthesize, and operationalize this context so nothing falls through the cracks.
This guide covers AI workflows for every Agile ceremony, plus skills you can deploy this sprint.
AI-Enhanced Sprint Planning
The Problem
Sprint planning often becomes a debate about estimates, with half the context missing and nobody remembering what was discussed last sprint.
The Workflow
Previous Sprint Data ──→ NotebookLM ──→ Context Brief
│
User Stories ──→ Claude Skill ──→ Refined Stories + Acceptance Criteria
│
Planning Notes ──→ Gemini Gem ──→ Sprint Summary + CommitmentsPre-Planning Brief (NotebookLM)
Create a notebook: “Sprint Planning Context”
Upload:
- Last sprint’s retrospective notes
- Current backlog (exported from Jira/Linear)
- Technical debt register
- Product roadmap or quarterly goals
Query before planning: “Based on last sprint’s retro and our current backlog, what are the top 3 risks for the upcoming sprint?”
This gives the team a grounded discussion starting point instead of walking in cold.
Story Refinement Skill (Claude)
---
name: Story Refiner
description: Transform rough user stories into well-structured stories with acceptance criteria
version: 1.0.0
---## Persona
You are a senior product owner with expertise in writing user stories
that are clear, testable, and appropriately scoped.
## Task
Given a rough user story or feature description:
1. Rewrite as a proper user story (As a... I want... So that...)
2. Break down if too large (>8 story points worth of work)
3. Write 3-5 acceptance criteria using Given/When/Then format
4. Identify edge cases and assumptions
5. Suggest technical considerations for the dev team
## Format
### User Story
**As a** [role]
**I want** [action]
**So that** [benefit]
**Story Points Estimate**: [S/M/L] with reasoning
### Acceptance Criteria
1. **Given** [context] **When** [action] **Then** [result]
2. ...
### Edge Cases
- [Edge case 1 with suggested handling]
### Technical Notes
- [Dependencies, integration points, risks]
### Questions for PO
- [Anything that needs clarification before development]
## Rules
- Stories should be completable in one sprint
- If a story requires more than 3 days of work, suggest splitting
- Acceptance criteria must be testable — no vague requirements
- Every story needs at least one edge case identified
- Flag dependencies on other stories or teamsSprint Summary Gem (Gemini)
After planning, create a clear record:
# Purpose
Generate structured sprint planning summaries from meeting
notes and story discussions.
# Format
## Sprint [X] Plan — [Team Name]
**Sprint Goal**: [One sentence goal]
**Duration**: [Start] — [End]
**Capacity**: [X story points / X team members]
### Committed Stories
| # | Story | Points | Owner | Risk |
|---|-------|--------|-------|------|
### Sprint Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
### Dependencies
- [External dependency → action needed]
### Carry-over from Last Sprint
- [Story] — reason: [why it wasn't completed]AI-Enhanced Daily Standups
Async Standup Workflow
For teams that do async standups (or want to supplement sync ones):
Claude Skill: Standup Synthesizer
---
name: Standup Synthesizer
description: Synthesize async standup updates into team-level summary
---
## Task
Given individual standup updates from team members:
1. Synthesize into a team-level summary
2. Identify blocked items that need immediate attention
3. Highlight dependencies between team members' work
4. Flag items that have been "in progress" for 3+ days
## Format
### 🚀 Team Progress — [Date]
**Overall Status**: 🟢 On Track / 🟡 At Risk / 🔴 Blocked
#### Completed Yesterday
- [What was finished and by whom]
#### In Progress Today
- [What's being worked on, with owners]
#### ⚠️ Blockers (Need Attention)
| Blocker | Owner | Blocked Since | Suggested Action |
#### 🔗 Dependencies
| Person A working on X | depends on | Person B completing Y |
#### 📊 Sprint Burndown Note
- Stories completed: [X/Y]
- Days remaining: [Z]
- On pace: [Yes/No — if no, what needs to change]AI-Enhanced Retrospectives
Before the Retro (NotebookLM)
Create a “Sprint [X] Retrospective” notebook:
Upload:
- Sprint planning summary
- Sprint burndown data
- Incident reports (if any)
- Customer feedback received during sprint
- Previous retrospective action items
Pre-retro query: “Based on the sprint data and incidents, what themes should we discuss in our retrospective?”
During the Retro (Gemini Gem)
Create a Gem: “Retro Facilitator”
# Purpose
Help facilitate effective sprint retrospectives by organizing
feedback and identifying actionable improvements.
# Behavior
- Categorize input into: What went well / What could improve / Action items
- For each "could improve" item, suggest a specific, measurable action
- Connect themes across items (e.g., "3 out of 5 items relate to communication")
- Reference previous retro action items to check follow-through
- Keep tone constructive — focus on systems, not individuals
# Format
## Sprint [X] Retrospective Summary
### 🟢 What Went Well
- [Item with specific example]
### 🔴 What Could Improve
- [Item] → **Suggested Action**: [Specific, measurable improvement]
### 🎯 Action Items (Max 3)
| # | Action | Owner | Measure of Success | Due |
|---|--------|-------|-------------------|-----|
### 📊 Previous Action Items Follow-up
| Action from Sprint [X-1] | Status | Impact |After the Retro (Claude Skill)
Retro Action Tracker Skill:
---
name: Retro Action Tracker
description: Track retrospective action items and measure improvement
---
## Task
Given retrospective summaries from multiple sprints:
1. Track action item completion rate
2. Identify recurring themes (problems that keep appearing)
3. Measure whether previous actions had the intended effect
4. Suggest systemic fixes for recurring problems
## Format
### Retrospective Health Report — [Team]
#### Action Item Completion
| Sprint | Actions Committed | Completed | Completion Rate |
| Last 3 sprints... |
#### Recurring Themes
| Theme | Appeared in Sprints | Root Cause Hypothesis |
(Any theme appearing 3+ times needs a systemic solution)
#### Systemic Recommendations
1. [Recommendation based on data patterns]AI-Enhanced Backlog Refinement
Story Quality Checker (Claude Skill)
Run your backlog through this before refinement sessions:
---
name: Backlog Quality Checker
description: Audit backlog for story quality, readiness, and technical debt
---
## Task
Given a set of backlog items:
1. Score each on the INVEST criteria
(Independent, Negotiable, Valuable, Estimable, Small, Testable)
2. Flag stories missing acceptance criteria
3. Identify stories that are too large or vague
4. Suggest grouping by theme or dependency
5. Estimate technical debt items vs feature work ratio
## Format
### Backlog Health Report
**Stories Analyzed**: [X]
**Ready for Sprint**: [X] (have ACs, properly sized, independent)
**Needs Refinement**: [X]
**Too Large**: [X]
**Missing Info**: [X]
#### Story-by-Story Assessment
| Story | INVEST Score | Status | Issues |
| [story title] | [I:✅ N:✅ V:✅ E:❌ S:✅ T:❌] | Needs Work | Missing ACs, not estimable |
#### Technical Debt Ratio
- Feature stories: [X%]
- Tech debt stories: [X%]
- Recommended ratio: 70/30 → Current: [assessment]
#### Suggested Refinement Focus
1. [Story most needing refinement — why]
2. [Second priority]
3. [Third priority]Sprint Metrics Dashboard (NotebookLM)
Setup
Create a persistent notebook: “[Team] Sprint Metrics”
After each sprint, upload:
- Sprint summary
- Retrospective notes
- Burndown chart data
- Team satisfaction survey results
Quarterly Analysis
Query: “Based on the last 6 sprints, what are the trends in our velocity, quality, and team satisfaction? What patterns predict a problematic sprint?”
This gives you data-driven insights that would take hours to compile manually.
Implementation Playbook
Week 1: Foundation
- Create team’s skill library folder structure
- Build Story Refiner skill
- Build Standup Synthesizer skill
- Test both with real data from current sprint
Week 2: Ceremonies
- Build Retro Facilitator Gem
- Build Sprint Summary Gem
- Create Sprint Context notebook in NotebookLM
- Use all tools in actual ceremonies this sprint
Week 3: Refinement
- Build Backlog Quality Checker
- Build Retro Action Tracker
- Review feedback from team on Week 2 tools
- Refine skills based on real usage
Week 4: Metrics
- Set up Sprint Metrics notebook
- Establish baseline measurements (time per ceremony, quality scores)
- Present results to team — get buy-in for continued use
- Document lessons learned
Team Adoption Tips
Start with the pain point: Don’t roll out AI for every ceremony at once. Start with the one that’s most painful for your team (usually retros or planning).
Make it opt-in first: Let early adopters use the tools, share their results, and create pull rather than push.
Measure before and after: Track time spent in ceremonies and output quality. Hard numbers beat opinions.
Keep humans in the loop: AI generates drafts and summaries. Humans make decisions. Never let AI replace the team’s judgment.
Iterate in public: Share skill improvements with the team. Show that the tools get better because of team feedback.