agile-product-owner

---
name: agile-product-owner
description: Use when writing user stories, creating acceptance criteria, planning sprints, estimating story points, breaking down epics, or prioritizing the product backlog.
category: Product
version: 1.0.0
tools: []
---

# Agile Product Owner

Backlog management and sprint execution toolkit: user story generation, acceptance-criteria patterns, sprint planning, and velocity tracking.

## What Makes This Approach Different

- Capacity math grounded in reality: sprint capacity is velocity × availability factor, not hope.
- Acceptance-criteria depth scaled by story size, so large items don't get under-specified.
- A weighted prioritization formula that stays consistent: value 40%, impact 30%, risk 15%, effort 15%.
- Five concrete epic-splitting techniques to prevent oversized stories.
- INVEST validation built into every workflow step, not left as vague guidance.

## User Story Generation

1. Identify the persona who benefits from the feature.
2. Define the action or capability needed.
3. Articulate the benefit or value delivered.
4. Write acceptance criteria in Given-When-Then form.
5. Estimate story points on the Fibonacci scale.
6. Validate against the INVEST criteria below.
7. Add to the backlog with a priority.

Template: "As a [persona], I want to [action/capability], so that [benefit/value]." Example: "As a marketing manager, I want to export campaign reports to PDF, so that I can share results with stakeholders who don't have system access."

Story types: **Feature** ("As a user, I want to filter search results so that I find items faster"), **Improvement** ("As a user, I need faster page loads to complete tasks without frustration"), **Bug Fix** ("As a user, I expect my cart to persist when I refresh the page"), **Enabler** ("As a developer, I need to implement caching to enable instant search").

Common personas and their typical needs: End User (efficiency, simplicity, reliability — daily usage), Administrator (control, visibility, security — system management), Power User (automation, customization, shortcuts — expert workflows), New User (guidance, learning, safety — onboarding).

## Acceptance Criteria

Given-When-Then template: "Given [precondition], When [action/trigger], Then [expected outcome]." Example: "Given the user is logged in with valid credentials, When they click the 'Export' button, Then a PDF download starts within 2 seconds."

Cover five categories per story: Happy Path, Validation (reject invalid/empty input), Error Handling (user-friendly message on API failure), Performance (e.g., completes within 2 seconds), and Accessibility (keyboard-navigable).

Minimum acceptance-criteria count scales with story size: 1–2 points → 3–4 criteria; 3–5 points → 4–6 criteria; 8 points → 5–8 criteria; 13+ points → split the story instead of writing more criteria.

## Epic Breakdown

1. Define epic scope and success criteria.
2. Identify all personas affected.
3. List all capabilities needed per persona.
4. Group capabilities into logical stories.
5. Validate each story is ≤8 points.
6. Identify dependencies between stories.
7. Sequence for incremental delivery.

Five splitting techniques: **by workflow step** (e.g., "Checkout" → add-to-cart + enter-payment + confirm-order), **by persona** (e.g., "Dashboard" → admin dashboard + user dashboard), **by data type** (e.g., "Import" → import-CSV + import-Excel), **by operation** (CRUD: create/edit/delete as separate stories), and **happy-path-first** (basic flow, then error handling, then edge cases as separate stories).

Example — a 34-point "User Dashboard" epic splits into: view key metrics (5 pts, end user), customize layout (5 pts, power user), export data to CSV (3 pts, end user), share with team (5 pts, end user), set up alerts (5 pts, power user), filter by date range (3 pts, end user), admin overview (5 pts, admin), and enable caching (3 pts, enabler) — eight independently deliverable stories instead of one unsized epic.

## Sprint Planning

1. Calculate team capacity: average velocity × availability factor.
2. Confirm the sprint goal with stakeholders.
3. Select stories from the prioritized backlog.
4. Fill to 80–85% of capacity as committed work.
5. Add 10–15% more as stretch goals.
6. Identify dependencies and risks.
7. Break complex stories into tasks.

Capacity example: average velocity 30 points × 90% availability (one member partially out) = 27-point adjusted capacity → commit to 23 points (85% of 27), hold 4 points (15%) as stretch. Availability factors: full sprint with no time off = 1.0; one member out 50% = 0.9; a holiday in the sprint = 0.8; multiple members out = 0.7.

## Backlog Prioritization

Priority tiers: **Critical** (blocking users, security, data loss — fix immediately), **High** (core functionality, key user needs — this sprint), **Medium** (improvements — next 2–3 sprints), **Low** (nice-to-have — backlog).

Weighted prioritization factors: Business Value 40% (revenue impact, user demand, strategic alignment), User Impact 30% (how many users, how often), Risk/Dependencies 15% (technical risk, external dependencies), Effort 15% (size, complexity, uncertainty).

## INVEST Validation

Before adding any story to a sprint, check it against all six letters: **I**ndependent (no blocking dependencies on other uncommitted stories), **N**egotiable (implementation is flexible, multiple approaches possible), **V**aluable (clear benefit stated in the "so that" clause), **E**stimable (the team understands it well enough to size it), **S**mall (fits in one sprint, ≤8 points), **T**estable (has clear, verifiable acceptance criteria).

## Sprint Health Metrics

| Metric | Formula | Target |
|--------|---------|--------|
| Velocity | Points completed per sprint | Stable ±10% |
| Commitment Reliability | Completed ÷ Committed | >85% |
| Scope Change | Points added/removed mid-sprint | <10% |
| Carryover | Points not completed | <15% |

Track velocity across recent sprints and plan the next commitment near the trailing average, adjusted down if the trend is unstable.

## Definition of Done

A story is complete only when: code is complete and peer-reviewed, unit tests are written and passing, acceptance criteria are verified, documentation is updated, it's deployed to staging, the product owner has accepted it, and no critical bugs remain.

## Sprint Loading Output

When presenting a finished sprint plan, separate committed from stretch work explicitly, tag each item with its priority (High/Medium/Low) and point value, and total both columns against the capacity figure so the 80–85%/10–15% split is visible at a glance — e.g. "Sprint Capacity: 27 points, Committed: 23 points, Stretch: 4 points" followed by the tagged item list. For a generated story, always show the INVEST checklist as a pass/fail line per letter alongside the story text and its acceptance criteria, so validation is auditable rather than implied.

## Related Disciplines

Velocity data and sprint ceremonies (standup, review, retro) belong to sprint facilitation and complement this backlog work. RICE-style prioritization from broader product-management practice feeds directly into backlog ordering here.