Sprint Planning & Roadmap Communication

Here are this week's engineering standup notes:

${standupNotes}

Convert these into a stakeholder-friendly weekly update for: ${audience}

FORMAT:
**Subject:** ${projectName} — Week of ${week} Update

**Progress Summary** (3-5 bullets, non-technical language)
Focus on outcomes and deliverables, not implementation details. "Users can now export reports as PDF" not "Implemented PDF generation using Puppeteer."

**Key Milestones**
| Milestone | Status | Expected Date |
Use: ✅ Complete, 🔄 In Progress (X% done), ⏳ Not Started, ⚠️ At Risk

**Blockers or Risks** (only if relevant)
Anything that could affect the timeline. Frame as business impact: "The billing integration delay may push the launch from March 15 to March 22" not "Stripe API rate limiting is blocking our migration script."

**Next Week Preview**
What to expect in the next update. Set expectations for what's coming.

**Demo-Ready Items**
Anything stakeholders can see or test right now. Include a link or screenshot description if available.

Tone: ${tone}. Keep the total update under 250 words.

I need to plan our next sprint. Here's what's competing for attention:

BACKLOG ITEMS:
${backlogItems}

CONSTRAINTS:
- Sprint length: ${sprintLength}
- Available capacity: ${capacity}
- Hard deadline items: ${deadlines}

PRIORITIZATION CRITERIA:
- Business impact (revenue, retention, or customer satisfaction)
- Customer requests / support ticket volume
- Technical dependencies (does anything block other work?)
- Strategic alignment with ${quarterGoal}

Help me plan the sprint:

1. **PRIORITY STACK RANK**
Rank every item by weighted score:
| Item | Business Impact (1-5) | Urgency (1-5) | Effort (S/M/L) | Dependencies | Rank |

2. **RECOMMENDED SPRINT SCOPE**
Given ${capacity} capacity, here's what fits:
- Must do (committed)
- Stretch goal (if things go well)
- Explicitly deferred (and why)

3. **DEPENDENCY MAP**
Which items must be done before others? Which can be parallelized?

4. **RISK FLAGS**
Any items that seem underestimated, have unclear requirements, or depend on external teams?

5. **SPRINT GOAL**
Write a one-sentence sprint goal that captures the theme. "By the end of this sprint, [who] can [do what] because [we built what]."

Here's our product roadmap for ${timeframe}:

${roadmapItems}

Create three versions of this roadmap:

**VERSION 1: ENGINEERING** (detailed, for internal planning)
| Quarter | Epic | Key Tasks | Effort | Dependencies | Owner |
Include technical details, architecture decisions, and risk factors.

**VERSION 2: EXECUTIVE / BOARD** (strategic, for leadership)
| Theme | What We're Building | Why It Matters | Expected Impact | Timeline |
No technical details. Focus on business outcomes and metrics. Max 1 page.

**VERSION 3: CUSTOMER-FACING** (for customer advisory board or public roadmap)
| Timeframe | What's Coming | How It Helps You |
Use "Now / Next / Later" framing instead of specific dates. No internal details.
- Now: Currently in development, shipping within 4 weeks
- Next: Planned for next quarter
- Later: On our radar, timeline TBD

For each version, also write a 2-sentence narrative intro. The engineering version can be blunt. The executive version should tie to strategy. The customer version should generate excitement without overpromising.

Here are the technical release notes for version ${version}:

${technicalNotes}

Write customer-facing release notes:

1. **HEADLINE FEATURES** (1-3 items that customers will notice and care about)
For each:
- Feature name (customer-friendly, not internal codename)
- What it does (1-2 sentences, plain English)
- Why it matters (what problem it solves or what it enables)
- How to use it (brief instruction or link to docs)

2. **IMPROVEMENTS** (3-5 items)
Smaller enhancements, performance improvements, UX tweaks.
One line each. Focus on the user benefit: "Reports load 3x faster" not "Optimized database queries."

3. **BUG FIXES** (keep it brief)
Only include fixes that customers would have noticed. Group minor fixes as "Various stability and performance improvements."

4. **COMING SOON** (optional teaser)
One sentence previewing what's in the next release.

Tone: ${tone}. Keep the total under 300 words.

I'm uploading retro notes from the last ${retroCount} sprints. Analyze them for patterns:

${retroNotes}

1. **RECURRING THEMES**
What keeps coming up across multiple retros?
| Theme | # of Sprints Mentioned | Getting Better or Worse? |

2. **WHAT'S ACTUALLY IMPROVING**
From the "what went well" sections — are the improvements sticking? Or do we celebrate something one sprint and lose it the next?

3. **PERSISTENT PROBLEMS**
Things that show up in "what didn't go well" multiple times. If we keep talking about it but don't fix it, that's a process failure.
| Problem | Times Mentioned | Was an Action Item Created? | Was It Completed? |

4. **ACTION ITEM COMPLETION RATE**
How many retro action items actually get done? If the rate is below 50%, the retro process itself needs fixing.

5. **TOP 3 RECOMMENDATIONS**
Based on the patterns:
- One process change that would have the biggest impact
- One communication improvement
- One thing to stop doing

Keep the analysis focused on actionable changes, not observations.