| name | product |
| description | Use when the user asks about "user story", "acceptance criteria", "PRD", "product requirements", "roadmap", "sprint planning", "estimation", "prioritization", "RICE", "MoSCoW", "MVP", "agile", "scrum", "kanban", "backlog", "retrospective", "stakeholder", or needs product management and agile methodology knowledge.
|
| keywords | ["user story","acceptance criteria","PRD","product requirements","roadmap","sprint planning","estimation","prioritization","RICE","MoSCoW","MVP","agile","scrum","kanban","backlog","retrospective","stakeholder"] |
Product Management & Agile Skill
Comprehensive guide for product management practices, agile methodologies, and project planning for software teams.
Methodology Decision Tree
What's your team like?
├── Small team (2-5), fast-moving, continuous delivery?
│ └── Kanban (flow-based, no sprints)
├── Team of 5-9, regular releases, needs structure?
│ └── Scrum (sprints, ceremonies, roles)
├── Small team, 6-week cycles, appetite-based?
│ └── Shape Up (Basecamp method)
├── Large org, multiple teams?
│ ├── Need coordination? → Scrum with scaled framework (LeSS, SAFe)
│ └── Teams are independent? → Kanban per team
└── Solo developer or pair?
└── Personal Kanban or simple task list
| Methodology | Cadence | Key concepts | Best for |
|---|
| Scrum | 1-2 week sprints | Sprint backlog, ceremonies, roles | Teams needing rhythm and predictability |
| Kanban | Continuous | WIP limits, pull-based, flow metrics | Maintenance, support, continuous delivery |
| Shape Up | 6-week cycles | Shaping, betting, appetite | Product-driven teams, small orgs |
| XP | 1-2 week iterations | Pair programming, TDD, CI | Engineering-heavy teams |
User Story Format and Examples
Format
As a [type of user],
I want [goal/desire],
So that [benefit/reason].
Good Examples
As a team admin,
I want to invite members by email,
So that I can quickly onboard my team.
As a billing manager,
I want to download PDF invoices for past payments,
So that I can submit them for expense reimbursement.
As a new user,
I want to see a guided tour on first login,
So that I understand how to use the key features.
Story Sizing Guidance
| Size | Complexity | Example |
|---|
| XS | Config change, copy update | Change button text |
| S | Single component, clear scope | Add tooltip to icon |
| M | Feature with 2-3 components | Build settings form |
| L | Multi-component, API + UI | Implement team invitations |
| XL | Should be broken down | Full auth system — split into stories |
Acceptance Criteria Patterns
Given/When/Then (Gherkin)
Feature: Team member invitation
Scenario: Admin invites a new member
Given I am logged in as a team admin
When I enter a valid email address and click "Send Invite"
Then the invitee receives an invitation email
And a pending invitation appears in the team members list
Scenario: Invitee accepts invitation
Given I received a team invitation email
When I click the invitation link
Then I am added to the team with "member" role
And I see the team dashboard
Scenario: Admin invites existing member
Given I am logged in as a team admin
When I enter an email of an existing team member
Then I see an error message "This user is already a team member"
And no duplicate invitation is sent
Checklist Format (simpler)
### Acceptance Criteria
- [ ] Email invitation is sent with correct team name and inviter name
- [ ] Invitation link expires after 7 days
- [ ] Existing team members cannot be re-invited
- [ ] Pending invitations are visible to admins
- [ ] Invitee can accept or decline the invitation
- [ ] Rate limit: max 10 invitations per hour per team
PRD Template Structure
# PRD: [Feature Name]
## Overview
One paragraph describing what we're building and why.
## Problem Statement
- What problem does this solve?
- Who experiences this problem?
- How are they solving it today?
## Goals & Success Metrics
| Goal | Metric | Target |
|------|--------|--------|
| Increase activation | % users completing onboarding | 40% → 60% |
| Reduce support tickets | Tickets about X per week | 50 → 10 |
## User Stories
1. As a [user], I want [goal] so that [benefit]
2. ...
## Scope
### In Scope
- Feature A
- Feature B
### Out of Scope
- Feature C (future consideration)
## Design
[Link to Figma / wireframes]
## Technical Considerations
- API changes needed
- Database schema changes
- Third-party integrations
- Performance implications
## Milestones
| Milestone | Description | Target Date |
|-----------|-------------|-------------|
| M1 | Core API + basic UI | Week 1 |
| M2 | Full UI + edge cases | Week 2 |
| M3 | Testing + polish | Week 3 |
## Open Questions
- [ ] Question 1
- [ ] Question 2
## Risks
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Third-party API instability | Medium | High | Build retry logic + fallback |
Prioritization Frameworks
RICE Score
RICE = (Reach × Impact × Confidence) / Effort
| Factor | Scale | Description |
|---|
| Reach | # of users/quarter | How many users will this affect? |
| Impact | 0.25, 0.5, 1, 2, 3 | How much will it move the metric? (3 = massive) |
| Confidence | 50%-100% | How sure are we? |
| Effort | Person-weeks | How much work? |
Example:
| Feature | Reach | Impact | Confidence | Effort | RICE |
|---|
| Onboarding wizard | 500 | 2 | 80% | 3 | 267 |
| Dark mode | 200 | 0.5 | 90% | 2 | 45 |
| Export to CSV | 100 | 1 | 100% | 1 | 100 |
MoSCoW Method
| Priority | Meaning | Guidance |
|---|
| Must have | Non-negotiable, launch blocker | Without this, the release fails |
| Should have | Important but not critical | Painful to leave out, but workarounds exist |
| Could have | Desirable, nice-to-have | Only if time allows |
| Won't have | Explicitly excluded this time | Acknowledged but deferred |
ICE Score
ICE = Impact × Confidence × Ease
Simpler than RICE — each factor scored 1-10. Good for quick prioritization in small teams.
Kano Model
| Category | User satisfaction | Example |
|---|
| Must-be | Expected, absence = frustration | Login, password reset |
| Performance | More = better, linear satisfaction | Speed, storage quota |
| Attractive | Delighters, absence is OK | AI features, smart defaults |
| Indifferent | Users don't care | Internal refactoring |
| Reverse | Causes dissatisfaction | Forced tutorials |
MVP Scoping
Must-Have vs Nice-to-Have Matrix
High Impact
│
MUST HAVE │ SHOULD HAVE
(launch) │ (fast follow)
────────────────┼────────────────
COULD HAVE │ WON'T HAVE
(if time) │ (later)
│
Low Impact
←─── Low Effort ──── High Effort ───→
MVP Scoping Questions
- What is the one core job this product does?
- What is the minimum to validate the hypothesis?
- What can we fake or do manually? (Wizard of Oz)
- What features can be added after launch?
- What is the simplest version that delivers value?
Scope Cutting Techniques
| Technique | Description | Example |
|---|
| Reduce cases | Support only the common case | Only email login (no social) |
| Manual backend | Automate later | Admin manually approves accounts |
| Fewer options | One way to do things | Single pricing plan |
| Read before write | Show data before editing | Dashboard first, settings later |
| Time-box | Fixed time, flexible scope | "What can we ship in 2 weeks?" |
Estimation Patterns
Story Points (Fibonacci)
| Points | Complexity | Example |
|---|
| 1 | Trivial, well-understood | Fix typo, change color |
| 2 | Simple, small scope | Add form field with validation |
| 3 | Moderate, clear approach | New API endpoint + tests |
| 5 | Significant, some unknowns | Multi-step form with API integration |
| 8 | Complex, many parts | Real-time notification system |
| 13 | Very complex, split it | Full auth system (should be broken down) |
T-Shirt Sizing
| Size | Rough time | When to use |
|---|
| XS | < 2 hours | Quick fixes, config changes |
| S | 2-4 hours | Small features, bug fixes |
| M | 1-2 days | Standard features |
| L | 3-5 days | Complex features |
| XL | 1-2 weeks | Epic-level, break down further |
No-Estimates Approach
Instead of estimating, focus on:
- Break all work into similarly-sized small tasks (1-2 days max)
- Track throughput (tasks completed per week)
- Forecast using Monte Carlo simulation on historical data
Sprint Ceremony Reference
For 2-Week Sprints
| Ceremony | Duration | Purpose | Output |
|---|
| Sprint Planning | 2 hours | Select and commit to sprint work | Sprint backlog |
| Daily Standup | 15 min | Sync, unblock | Updated board |
| Sprint Review | 1 hour | Demo completed work | Stakeholder feedback |
| Sprint Retrospective | 1 hour | Improve process | Action items |
| Backlog Refinement | 1 hour | Clarify upcoming stories | Refined, estimated stories |
Standup Format
1. What I completed yesterday
2. What I'm working on today
3. Any blockers?
Anti-patterns: Status report to manager, going over 15 min, problem-solving during standup (take it offline).
Retrospective Formats
| Format | How it works | Best for |
|---|
| Start/Stop/Continue | Three columns | Simple, quick |
| Glad/Sad/Mad | Emotional check-in | After difficult sprints |
| 4Ls | Liked, Learned, Lacked, Longed for | Balanced reflection |
| Sailboat | Wind (helpers), Anchor (blockers), Rocks (risks) | Visual teams |
Roadmap Types
Now / Next / Later (Recommended for Startups)
┌─────────────────┬──────────────────┬─────────────────┐
│ NOW │ NEXT │ LATER │
│ (This sprint) │ (Next 1-2 mo) │ (3-6 months) │
├─────────────────┼──────────────────┼─────────────────┤
│ Team invitations │ Role-based access │ SSO / SAML │
│ Email notifs │ Notification prefs│ Slack integration│
│ Billing page │ Usage analytics │ Custom reports │
└─────────────────┴──────────────────┴─────────────────┘
Roadmap Type Comparison
| Type | Best for | Risk |
|---|
| Now/Next/Later | Startups, uncertain environments | Less precision |
| Timeline | Enterprise, committed dates | Pressure to meet dates |
| Outcome-based | Product-led teams | Harder to communicate |
| Kanban board | Continuous delivery | Less strategic view |
Stakeholder Communication Templates
Weekly Status Update
## Weekly Update — [Date]
### Highlights
- Shipped team invitations (3 stories, 8 points)
- Started billing integration
### Metrics
- Sprint velocity: 21 points (target: 20)
- Bug count: 3 open (down from 7)
### Blockers
- Waiting on Stripe account approval
### Next Week
- Complete billing flow
- Start notification system
### Risks
- Stripe approval delay could push billing launch by 1 week
Feature Launch Announcement (Internal)
## [Feature Name] — Shipped!
**What**: Brief description of the feature
**Why**: Problem it solves, metric it moves
**Who**: Target users
**How to test**: Steps or link to staging
**Rollout plan**: % rollout, timeline to 100%
**Known limitations**: What doesn't work yet
**Feedback**: Where to report issues
Common Mistakes
| Mistake | Problem | Fix |
|---|
| No acceptance criteria | Scope creep, ambiguous "done" | Write AC before development starts |
| Estimating in time, not complexity | Pressure, inaccurate forecasting | Use story points or t-shirt sizes |
| Skipping retrospectives | Same problems repeat | Make retros mandatory, rotate formats |
| Too many WIP items | Nothing finishes | Set WIP limits (2-3 per developer) |
| Sprint scope changes | Constant disruption | Protect sprint commitment, use "next sprint" |
| PRD without success metrics | No way to evaluate outcome | Define metrics before building |
| Roadmap as promise | Missed expectations | Use "Now/Next/Later" without dates |
| Gold plating | Over-building beyond requirements | Deliver MVP, iterate with feedback |
| No user research | Building wrong things | Talk to 5 users before writing PRD |
| Ignoring technical debt | Slowing velocity over time | Budget 15-20% of sprint for tech debt |
Pre-Delivery Checklist
References
