❌ FORBIDDEN:
- "The app should be fast"
- "Support many users"
- "Good user experience"
- "The system should be reliable"
- "Easy to use interface"

✅ REQUIRED:
- "Page load time < 2s on 4G, < 500ms on WiFi (P95)"
- "Support 10,000 concurrent users with 99.9% uptime"
- "NPS > 50, Task completion rate > 85%"
- "99.9% availability, MTTR < 1 hour"
- "User can complete checkout in < 3 clicks"

❌ FORBIDDEN:
"We should add a search bar to the navigation"

✅ REQUIRED:
"Problem: Users can't find products quickly (40% exit rate on catalog).
They need a way to filter 1000+ products by attributes.
Proposed solutions: search bar, smart filters, AI recommendations."

❌ FORBIDDEN:
- Dependent stories that can't be delivered independently
- Stories without acceptance criteria
- Stories too large to complete in one sprint
- Stories without clear user value

✅ REQUIRED:
- [ ] Independent — Can be delivered alone
- [ ] Negotiable — Details can be discussed
- [ ] Valuable — Clear user/business value
- [ ] Estimable — Team can estimate effort
- [ ] Small — Fits in one sprint
- [ ] Testable — Has acceptance criteria

undefined

---

As a [persona/role],
I want to [action/goal],
So that [benefit/value].

Card          — Brief description on index card
              → Captures essence, not details
              → Placeholder for conversation

Conversation  — Discussion between team members
              → Explore edge cases
              → Clarify assumptions
              → Uncover hidden requirements

Confirmation  — Acceptance criteria
              → Defines "done"
              → Testable conditions
              → Given-When-Then format

Independent   — Story stands alone, minimal dependencies
Negotiable    — Details emerge through conversation
Valuable      — Delivers value to users or business
Estimable     — Team can estimate effort
Small         — Completable within one sprint
Testable      — Clear acceptance criteria

undefined

undefined

❌ Too technical
"As a user, I want the API to return a 200 status code"
→ Focus on user benefit, not implementation

❌ Too vague
"As a user, I want the system to be fast"
→ Define measurable performance targets

❌ Missing the "so that"
"As a user, I want to filter products by price"
→ Add the value: "so that I can find items within my budget"

❌ Too large (Epic)
"As a user, I want a complete e-commerce checkout experience"
→ Break into smaller stories: cart, address, payment, confirmation

Given [precondition/context]
When [action/trigger]
Then [expected outcome]

And [additional context/outcome]

✓ Keep scenarios focused (one behavior per scenario)
✓ Maintain clear separation of Given/When/Then
✓ Avoid UI-specific details (test behavior, not implementation)
✓ Make criteria testable and measurable
✓ Include both happy path and edge cases
✓ Use real user interactions, not hypothetical

undefined

undefined

For simpler features, use a checklist:

---

RICE Score = (Reach × Impact × Confidence) / Effort

Reach      — How many users affected per time period?
             (users/quarter, transactions/month)
Impact     — How much does it improve their experience?
             3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence — How certain are we?
             100% = High data, 80% = Medium, 50% = Low
Effort     — Person-months required
             (engineering + design + PM time)

ICE Score = (Impact + Confidence + Ease) / 3

Impact     — 1-10: How much business/user value?
Confidence — 1-10: How certain are we?
Ease       — 1-10: How easy to implement? (10 = very easy)

Must Have      — Critical for launch, non-negotiable
                 Without this, the product fails

Should Have    — Important but not vital
                 Painful to omit, but workarounds exist

Could Have     — Nice to have, "vitamins not painkillers"
                 Include if time/resources allow

Won't Have     — Explicitly out of scope
                 Defer to future releases

Basic Needs       — Must-haves, assumed by users
                    Absence = dissatisfaction, presence = neutral
                    Example: Website loads, checkout works

Performance       — More is better, linear satisfaction
                    Example: Faster page load, more payment options

Delighters        — Unexpected features that wow
                    Absence = neutral, presence = delight
                    Example: Free shipping, personalized recommendations

Indifferent       — Users don't care either way
                    Example: Animated logo, theme customization

Best practice: Combine frameworks

1. Use MoSCoW to define release scope
   → Separate must-haves from nice-to-haves

2. Use RICE to rank must-haves
   → Sequence within release based on impact

3. Use Kano to ensure balance
   → Don't over-invest in basics, under-invest in delight

Example:
- All "Must Have" items → Score with RICE → Build in RICE order
- Validate with Kano → Ensure we have delighters, not just basics

Initiatives    — Large strategic bets (12-24 months)
                 Example: "Expand to enterprise market"

Epics          — Major features (3-6 months)
                 Example: "SSO and enterprise authentication"

Stories        — User-facing functionality (1-2 weeks)
                 Example: "SAML login for enterprise users"

Tasks          — Technical implementation (1-3 days)
                 Example: "Set up SAML provider integration"

Bugs           — Defects to fix (varies)
                 Example: "Login fails on Safari 17"

Cadence: Weekly, 1 hour, mid-sprint

Activities:
1. Groom upcoming stories
   - Add acceptance criteria
   - Break down large stories
   - Clarify unknowns

2. Estimate effort
   - Planning poker or t-shirt sizes
   - Identify technical risks

3. Prioritize
   - Apply RICE/MoSCoW
   - Consider dependencies

4. Definition of Ready
   - [ ] User story is clear
   - [ ] Acceptance criteria defined
   - [ ] Dependencies identified
   - [ ] Designs available (if needed)
   - [ ] Estimated by team
   - [ ] No blocking questions

For regulated industries (healthcare, finance):

Requirement ID → User Story → Test Case → Implementation

Example:
REQ-AUTH-001: "System shall enforce 2FA for admin users"
  ↓
US-123: "As an admin, I want 2FA to secure my account"
  ↓
TEST-456: "Verify admin cannot login without 2FA code"
  ↓
PR-789: Implementation in auth-service

Use tools: Jira, Azure DevOps, Modern Requirements

❌ Vague: "The app should be fast"
✓ Specific: "Page load time < 2s on 4G, < 500ms on WiFi (p95)"

❌ Vague: "The product should be lightweight"
✓ Specific: "Weight < 500g including battery and accessories"

❌ Vague: "Support many users"
✓ Specific: "Handle 10,000 concurrent users with 99.9% uptime"

❌ Solution-focused:
"Add a search bar to the navigation menu"

✓ Problem-focused:
"Users can't find products quickly (exit rate 40% on catalog page).
They need a way to filter 1000+ products by attributes."

→ This allows the team to explore multiple solutions:
  - Search bar
  - Smart filters
  - Category navigation
  - AI recommendations

For each decision, explain WHY:

"We're building password reset via email (not SMS) because:
- 95% of users have verified email (only 60% have phone)
- Email is free, SMS costs $0.02 per message
- Competitors (Stripe, GitHub) use email
- SMS has security concerns (SIM swapping)"

Use short paragraphs, bullet points, tables

❌ Wall of text:
"The user authentication system should support multiple authentication
methods including email and password which is the default method that
most users will use but we should also support social login via Google
and GitHub which are commonly requested features and will reduce friction
during signup and we should also consider adding two-factor authentication
for security..."

✓ Structured:
**Authentication Methods:**
- Email + Password (default, 80% of users)
- Social login (Google, GitHub)
- Two-factor authentication (optional, security-conscious users)

**Rationale:**
- Reduce signup friction (social login)
- Support security best practices (2FA)
- Follow industry standards

✓ Use versioning: v1.0, v1.1, v2.0
✓ Track changes with comments
✓ Maintain changelog at top of doc
✓ Lock old versions (read-only)
✓ Link to source of truth (Figma, GitHub)

Example Changelog:
---

undefined

Review Process:
1. Draft PRD (PM)
2. Technical feasibility review (Engineering)
3. Design review (Design)
4. Legal/compliance review (if needed)
5. Stakeholder sign-off (Leadership)
6. Publish and socialize

Use RACI matrix:
- Responsible: PM (writes PRD)
- Accountable: Product Lead (final approval)
- Consulted: Engineering, Design, Marketing
- Informed: Leadership, Support, Sales

undefined

---