8 min read • Guide 788 of 877
Product Owner Responsibilities
The Product Owner bridges business and development. GitScrum provides tools for POs to manage backlogs, priorities, and stakeholder communication.
PO Responsibilities
Core Duties
PRODUCT OWNER ROLE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIMARY ACCOUNTABILITIES: │
│ │
│ 1. PRODUCT VISION │
│ ───────────────── │
│ • Define product strategy │
│ • Communicate vision to team │
│ • Align work with business goals │
│ • Make trade-off decisions │
│ │
│ 2. BACKLOG MANAGEMENT │
│ ──────────────────── │
│ • Create and maintain backlog │
│ • Order by priority/value │
│ • Keep backlog refined │
│ • Remove outdated items │
│ │
│ 3. REQUIREMENTS │
│ ───────────── │
│ • Write user stories │
│ • Define acceptance criteria │
│ • Clarify requirements │
│ • Provide context │
│ │
│ 4. STAKEHOLDER MANAGEMENT │
│ ───────────────────────── │
│ • Gather input from stakeholders │
│ • Communicate progress │
│ • Manage expectations │
│ • Shield team from chaos │
│ │
│ 5. ACCEPTANCE │
│ ─────────── │
│ • Review completed work │
│ • Accept or reject stories │
│ • Provide feedback │
└─────────────────────────────────────────────────────────────┘
Daily Activities
PO WEEKLY RHYTHM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DAILY: │
│ ────── │
│ • Available for team questions │
│ • Review completed work │
│ • Clarify requirements │
│ • Attend standup (optional but helpful) │
│ │
│ WEEKLY: │
│ ──────── │
│ • Backlog refinement with team │
│ • Stakeholder meetings │
│ • Priority review │
│ • Story writing │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPRINT CEREMONIES: │
│ │
│ PLANNING: │
│ • Present sprint goal │
│ • Explain top priorities │
│ • Answer questions │
│ • Confirm scope with team │
│ │
│ REFINEMENT: │
│ • Present upcoming stories │
│ • Clarify requirements │
│ • Accept team estimates │
│ │
│ DEMO: │
│ • Coordinate with stakeholders │
│ • Accept/reject completed work │
│ • Gather feedback │
│ │
│ RETRO: │
│ • Participate as team member │
│ • Hear team feedback │
│ • Commit to improvements │
└─────────────────────────────────────────────────────────────┘
Backlog Management
Prioritization
PRIORITIZATION APPROACH:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIORITIZATION FRAMEWORKS: │
│ │
│ VALUE VS EFFORT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ HIGH VALUE ││
│ │ │ ││
│ │ ┌───────────┼───────────┐ ││
│ │ │ Quick │ Big │ ││
│ │ │ Wins ★★★ │ Bets ★★ │ ││
│ │ LOW ────┼───────────┼───────────┤──── HIGH ││
│ │ EFFORT │ Maybe │ Avoid │ EFFORT ││
│ │ │ Later ★ │ ☆ │ ││
│ │ └───────────┼───────────┘ ││
│ │ │ ││
│ │ LOW VALUE ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORITY ORDER: │
│ 1. Quick Wins (high value, low effort) │
│ 2. Big Bets (high value, high effort) │
│ 3. Maybe Later (low value, low effort) │
│ 4. Avoid (low value, high effort) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MOSCOW: │
│ M - Must have (required for MVP/release) │
│ S - Should have (important but not critical) │
│ C - Could have (nice to have) │
│ W - Won't have (explicitly out of scope) │
│ │
│ BACKLOG EXAMPLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PRIORITY STORY MOSCOW ││
│ │ ──────── ───── ────── ││
│ │ 1 User login MUST ││
│ │ 2 Password reset MUST ││
│ │ 3 Social login SHOULD ││
│ │ 4 Remember me COULD ││
│ │ 5 Biometric auth WON'T ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Writing Stories
USER STORY QUALITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STORY TEMPLATE: │
│ │
│ AS A [user type] │
│ I WANT [capability] │
│ SO THAT [benefit] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ GOOD STORY EXAMPLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY-456: Receive order shipping notification ││
│ │ ││
│ │ As a customer ││
│ │ I want to receive an email when my order ships ││
│ │ So that I know when to expect delivery ││
│ │ ││
│ │ ACCEPTANCE CRITERIA: ││
│ │ ☐ Email sent when order status = shipped ││
│ │ ☐ Email includes order number ││
│ │ ☐ Email includes tracking link ││
│ │ ☐ Email includes estimated delivery date ││
│ │ ☐ User can opt out in preferences ││
│ │ ││
│ │ CONTEXT: ││
│ │ Currently 30% of support tickets ask "where's my ││
│ │ order?" - this should reduce that by 50%. ││
│ │ ││
│ │ NOT IN SCOPE: ││
│ │ • Push notifications (future story) ││
│ │ • SMS notifications (future story) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INVEST CRITERIA: │
│ I - Independent (can be done alone) │
│ N - Negotiable (team can discuss how) │
│ V - Valuable (delivers user value) │
│ E - Estimable (team can estimate) │
│ S - Small (fits in a sprint) │
│ T - Testable (clear acceptance criteria) │
└─────────────────────────────────────────────────────────────┘
Stakeholder Management
Managing Expectations
STAKEHOLDER COMMUNICATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PO AS FILTER: │
│ │
│ STAKEHOLDERS ──→ PO ──→ TEAM │
│ │ │
│ Prioritizes │
│ Clarifies │
│ Buffers │
│ │
│ Without PO: │
│ Stakeholders ──→ Team (chaos!) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ STAKEHOLDER MEETINGS: │
│ │
│ INPUT GATHERING: │
│ "Tell me about the problem you're facing" │
│ "What would success look like?" │
│ "How would this help users?" │
│ │
│ DON'T: Let stakeholders dictate solutions │
│ DO: Understand the underlying need │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SAYING NO: │
│ │
│ "This is valuable. Here's why it's not top priority:" │
│ "We have X, Y, Z ahead of it because..." │
│ "If this is urgent, what should we deprioritize?" │
│ │
│ NEVER: "We'll try to fit it in" │
│ (Creates false expectations) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ STATUS UPDATES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STAKEHOLDER DASHBOARD ││
│ │ ││
│ │ Sprint 12 Progress ││
│ │ ═══════════════════════════░░░░░░░░░ 70% ││
│ │ ││
│ │ ✅ Login feature - Complete ││
│ │ 🔄 Password reset - In progress ││
│ │ 📅 Social login - Next sprint ││
│ │ ││
│ │ RISKS: ││
│ │ • API dependency may delay social login ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Working with Team
Collaboration
PO + TEAM DYNAMICS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PO DECIDES: │
│ ──────────── │
│ • WHAT to build (requirements) │
│ • WHY to build it (value) │
│ • WHEN it's needed (priority) │
│ • IF it's done (acceptance) │
│ │
│ TEAM DECIDES: │
│ ───────────── │
│ • HOW to build it (technical approach) │
│ • HOW LONG it takes (estimates) │
│ • HOW MUCH they can do (capacity) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ AVAILABILITY: │
│ │
│ ✅ GOOD PO: │
│ • Responds to questions same day │
│ • Available during refinement │
│ • Reviews work promptly │
│ • Clear when unavailable │
│ │
│ ❌ BAD PO: │
│ • "I'll get back to you" (never does) │
│ • Never in refinement │
│ • Stories sit waiting for acceptance │
│ • Team blocked waiting for decisions │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ACCEPTANCE: │
│ │
│ When team says "done": │
│ │
│ 1. Review against acceptance criteria │
│ 2. Test the functionality │
│ 3. Either ACCEPT or REJECT with feedback │
│ 4. If reject: Clear actionable feedback │
│ │
│ ACCEPT: "This meets the criteria, great work!" │
│ REJECT: "Tracking link isn't clickable (criteria 3)" │
│ │
│ Don't: Reject for things not in acceptance criteria │
│ Don't: Add new requirements after development │
└─────────────────────────────────────────────────────────────┘