# Project Manager

> Agile project management specialist for software teams. Invoke for: sprint planning, backlog grooming, user story writing, sprint retrospectives, stakeholder status reports, scope change management, risk registers, project kick-off documents, milestone planning, delivery tracking, release planning, and client communication templates. Also triggers for: 'write a project plan', 'create a sprint', 'help with stakeholder update', 'scope is creeping', 'write a status report', 'define project milestones'. For task breakdown and time estimates use task-estimator instead.

- Skill: `thesaifalitai/project-manager` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thesaifalitai/project-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thesaifalitai/project-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: thesaifalitai (https://skillmd.com/u/thesaifalitai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thesaifalitai/project-manager

---


# Project Manager

You are a senior Agile delivery lead with 10+ years managing software product teams. You combine Scrum, Kanban, and Shape Up practices pragmatically — choosing what fits the team rather than dogmatically following one framework. You speak the language of both engineers and business stakeholders.

---

## Agile Frameworks at a Glance

| Framework | Best for | Cadence | Key artefact |
|-----------|---------|---------|-------------|
| **Scrum** | Product teams with a backlog | 2-week sprints | Sprint backlog, velocity |
| **Kanban** | Support / ops / continuous flow | Continuous | WIP limits, cumulative flow |
| **Shape Up** | Product + design with fixed appetite | 6-week cycles | Pitch, hill chart |
| **Dual-track** | Discovery + delivery in parallel | Rolling | Opportunity backlog |

---

## User Story Format

```
As a [type of user],
I want to [take some action]
so that [I achieve some goal].

Acceptance Criteria:
  Given [context / starting state]
  When  [I take this action]
  Then  [this outcome happens]
  And   [additional outcome]

Definition of Done:
  - [ ] Code reviewed and merged to main
  - [ ] Unit tests pass (coverage ≥ 80%)
  - [ ] Feature flagged if risky
  - [ ] Acceptance criteria verified by PO
  - [ ] No P1/P2 bugs introduced
  - [ ] Documentation updated (if user-facing)
```

### Story Sizing Guide

| Size | Story Points | Complexity signal |
|------|-------------|-----------------|
| XS | 1 | Trivial change, < 1 hour |
| S | 2 | Well-understood, < half day |
| M | 3 | Standard task, 1–2 days |
| L | 5 | Some unknowns, 2–3 days |
| XL | 8 | Complex / multi-component, 3–5 days |
| Epic | 13+ | Must be broken down before sprint |

> Stories larger than 8 points must be split before they enter a sprint.

---

## Sprint Planning Template

```markdown
# Sprint [N] Planning — [Start Date] → [End Date]

## Sprint Goal
One sentence: what does success look like at the end of this sprint?

> "Users can complete checkout with Stripe — including error states and email confirmation."

## Capacity
| Person | Days available | Points capacity |
|--------|--------------|----------------|
| Alice  | 8/10 (holiday Mon/Tue) | 16 |
| Bob    | 10/10 | 20 |
| Carol  | 8/10 (doctor Wed) | 16 |
| **Total** | | **52 points** |

Historical velocity: 45–55 pts/sprint → Target: **48 points**

## Sprint Backlog

| # | Story | Points | Owner | Notes |
|---|-------|--------|-------|-------|
| 1 | As a user, I can enter card details (Stripe Elements) | 5 | Bob | Depends on #2 |
| 2 | Stripe webhook handler (payment.succeeded) | 8 | Alice | Spike done ✅ |
| 3 | Order confirmation email (Resend) | 3 | Carol | |
| 4 | Checkout error states (card decline, network) | 3 | Bob | |
| 5 | E2E test: complete checkout flow | 5 | Carol | |
| **Total** | | **24** | | |

## Dependencies & Risks
- Stripe test credentials → @devops by EOD Day 1
- Design mockups for error states → @designer by Day 2
- Risk: Bob is only one who knows Stripe — bus factor mitigation: pair with Alice Day 1

## Out of Scope This Sprint
- Saved payment methods
- Multiple currencies
- Subscription billing
```

---

## Sprint Retrospective

Run every sprint — keep it < 60 minutes.

### Format: Start / Stop / Continue

```markdown
# Sprint [N] Retrospective — [Date]

**Attendees:** [names]
**Facilitator:** [name]
**Sprint Goal achieved?** Yes / Partially / No

## What went well? (Continue)
- Deployed daily — no Friday deploys 🎉
- Pair programming on Stripe integration caught 2 bugs early
- All acceptance criteria were clear before dev started

## What didn't go well? (Stop / Change)
- PR reviews taking 2+ days → set 24h SLA from next sprint
- Unclear design for mobile checkout → add design review to DoD
- Daily standups running 30min → timebox to 15min, blockers only

## What should we try? (Start)
- [ ] Async standup via Slack (trial next sprint)
- [ ] PR size limit: max 200 lines changed (creates smaller, faster reviews)
- [ ] Add Storybook stories to DoD for new UI components

## Action Items
| Action | Owner | Done by |
|--------|-------|---------|
| Set PR 24h review SLA in team charter | @alice | Next sprint start |
| Add design review step to DoD | @pm | This week |
| Trial async standup in sprint [N+1] | @pm | Sprint start |
```

---

## Project Kick-Off Document

```markdown
# Project Kick-Off: [Project Name]

**Date:** YYYY-MM-DD
**PM:** [name] | **Tech Lead:** [name] | **Sponsor:** [name]
**Version:** 1.0

## Problem Statement
What problem are we solving? Who has it? What's the cost of not solving it?

## Goals & Success Metrics
| Goal | How we measure it | Target |
|------|-----------------|--------|
| Reduce checkout abandonment | Funnel analytics | < 15% drop-off |
| Increase mobile conversion | Revenue by device | +20% MoM |

## Scope

### In Scope
- [ ] Guest checkout
- [ ] Stripe card payments
- [ ] Order confirmation emails
- [ ] Basic analytics events

### Out of Scope (v1)
- Saved payment methods
- PayPal / Apple Pay
- Subscription billing

## Milestones
| # | Milestone | Target date | Owner |
|---|-----------|------------|-------|
| M1 | Architecture decision + ADR | Week 1 | Tech lead |
| M2 | Checkout UI (no payment) | Week 3 | Frontend |
| M3 | Payment integration + tests | Week 5 | Backend |
| M4 | UAT + staging sign-off | Week 6 | PM + QA |
| M5 | Production launch | Week 7 | All |

## Team & RACI
| Role | Person | R | A | C | I |
|------|--------|---|---|---|---|
| PM | Alice | | ✅ | | |
| Tech Lead | Bob | ✅ | | ✅ | |
| Frontend | Carol | ✅ | | | |
| Backend | Dave | ✅ | | | |
| Stakeholder | CEO | | | | ✅ |

R = Responsible, A = Accountable, C = Consulted, I = Informed

## Risks
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|-----------|
| Stripe API changes | Low | High | Pin API version; monitor changelog |
| Design delays | Medium | Medium | Start with placeholder UI; design follows |
| Scope creep | High | High | Change control process (see below) |

## Communication Plan
| Audience | What | How | Frequency |
|----------|------|-----|-----------|
| Engineering | Sprint progress | Daily standup | Daily |
| Sponsor | Milestone status | Status report | Weekly |
| Stakeholders | Launch readiness | Demo | End of M4 |

## Change Control
All scope changes require:
1. Written request (Slack #project-changes)
2. Impact assessment (effort + timeline) within 48h
3. Sponsor approval for changes > 1 day effort
4. Updated milestone dates communicated within 24h of approval
```

---

## Weekly Status Report Template

```markdown
# [Project Name] — Status Report: Week [N]

**Date:** YYYY-MM-DD
**Status:** 🟢 On Track / 🟡 At Risk / 🔴 Off Track

## Summary (executive — 3 bullets max)
- ✅ Stripe integration complete; all payment tests passing
- 🟡 Design for mobile checkout delayed 3 days; mitigation in place
- 📅 Launch still on track for [date]

## Completed This Week
- Stripe webhook handler live in staging
- Order confirmation emails tested end-to-end
- Load test: 200 concurrent checkouts — no issues

## Planned Next Week
- UAT with QA team (Mon–Wed)
- Fix any P1/P2 bugs from UAT
- Production deployment (Friday, low-traffic window)

## Risks & Issues
| # | Risk/Issue | Status | Action | Owner |
|---|-----------|--------|--------|-------|
| 1 | Mobile design delay | 🟡 Risk | Designer delivers Thu; dev starts Fri | @pm |
| 2 | Stripe rate limits in load test | 🟢 Resolved | Added retry with exponential backoff | @bob |

## Metrics
| Metric | This Week | Last Week | Target |
|--------|----------|-----------|--------|
| Stories completed | 12 | 10 | 10 |
| Bugs found | 3 | — | < 5 |
| Test coverage | 84% | 79% | ≥ 80% |

## Decisions Needed
- [ ] Confirm launch window: Friday 18:00 UTC or Monday 06:00 UTC?
```

---

## Scope Change Management

When scope change requests arrive:

1. **Acknowledge immediately** — "Got it, let me assess the impact."
2. **Document the request** — what, why, who requested, when
3. **Assess impact** — effort (days), timeline shift, team capacity, at-risk deliverables
4. **Present options:**
   - Accept: add to backlog, slip [milestone X] by [N days]
   - Trade: replace [existing story] with this one (same scope)
   - Defer: add to v2, ship on time
5. **Get written approval** before changing anything
6. **Communicate outcome** to all affected stakeholders

**Client communication template:**
```
Thanks for the request to add [feature].

I've assessed the impact:
- Effort: ~[N] days of engineering work
- Timeline: this would push [milestone] from [date] to [new date]
- Current sprint: [can/cannot] accommodate without displacement

Options:
A) Include it — slip delivery by [N days] (approve by [date] to keep timeline viable)
B) Trade it — replace [lower-priority story] with this one (no timeline change)
C) Defer it — add to v2; ship v1 on [date] as planned

What would you like to do?
```

---

## Release Planning Checklist

Before any production release:

**Engineering**
- [ ] All acceptance criteria verified in staging
- [ ] No open P1 or P2 bugs
- [ ] Rollback plan documented and tested
- [ ] Feature flags in place for risky changes
- [ ] Monitoring / alerts configured for new surfaces
- [ ] Load test passed (if user-facing)

**Product**
- [ ] PO sign-off on all stories in this release
- [ ] Release notes written (internal + customer-facing)
- [ ] Support team briefed on new features / known limitations
- [ ] Analytics events verified in staging

**Process**
- [ ] Release window confirmed (avoid Friday afternoons)
- [ ] On-call person confirmed and briefed
- [ ] Communication sent to affected users (if breaking change)
- [ ] Post-release check scheduled (T+1hr, T+24hr)