Scrum Product Owner – Basic Outline

I found it helpful to review my notes on the role of a Scrum Product Owner and place an outline here to which I can refer quickly.

Three Pillars of Scrum
- Transparency
- Inspection
- Adaptation
Iron Triangle (from Project Management)
- Scope
- Cost
- Schedule (Time)
Scrum Ceremonies
- Sprint Planning
  - all team members including Product Owner
  - Dev Team commits to complete a negotiated amount of work from the highest-priority PBIs (Product Backlog Items)
- Daily Scrum
  - Dev Team, ScrumMaster
    - What did I do yesterday?
    - What am I going to do today?
    - What impediments do I face?
  - presence of Product Owner can be very helpful to answer questions
- Sprint Review
  - mainly review what was accomplished
  - outside managers are encouraged to attend
- Sprint Retrospective
  - mainly review the team’s internal process
  - mostly just for Dev Team and ScrumMaster
- Product Backlog Refinement
  - Product Owner with Stakeholders, SMEs, Customers, Managers
  - Also work with ScrumMaster, less with Dev Team
Scrum Artifacts
- Product Backlog
- Sprint Backlog
- Product Increment
Product Owner Activities
- Inward-Facing: Work with the Scrum Team
  - Release Planning
  - Sprint Planning
  - Daily Scrum
  - Answer Questions
  - Validate PBI (Product Backlog Item)
  - Sprint Review
- Outward-Facing: Work outside the Scrum Team
  - Work with SMEs, Stakeholders, and Customers
  - Understands Needs
  - Validate Product
- Groom/Refine Backlog
  - Create PBIs (Product Backlog Items)
  - Split PBIs
  - Reorder the Product Backlog
Product Owner Responsibilities
- Gathers input from stakeholders
- Establishes a high-level vision and goals
- Obtains a budget
- Identifies ways to improve business value
- Optimizes ROI
- Establishes clear release criteria
- Prioritizes the product backlog
- evolves the product backlog
- clarifies user stories
- maintains a release burndown chart
Balance for Scrum Roles
- Product Owner: Build the Right Thing
- Development Team: Build the Thing Right
- ScrumMaster: Build the Thing Effectively
Levels of Planning (small -> large)
- Daily Planning
- Sprint Planning
- Release Planning
- Roadmap Planning
- Vision Planning
Scrum Overview
- Idea->Product Vision
- Roadmap
  - Initiation – Sprint 0
  - Releases 1-n
    - Sprint 1
      - Sprint Plan
      - Sprint (days)
        
        Day 1
        
        Day …
        
        Day n
      - Sprint Review
      - Sprint Retrospective
      - Produces a Product Increment
        
        Meets Definition of Done
        
        Increment usable by customer
        
        Release (final)
    - Sprint n
      - Sprint Plan
      - Sprint (days)
        
        Day 1
        
        Day …
        
        Day n
      - Sprint Review
      - Sprint Retrospective
      - Produces a Product Increment
        
        Meets Definition of Done
        
        Increment usable by customer
        
        Release (final)
    - Release Review
    - Release Retrospective
  - Final Release
Roadmapping
- Start from core functionality
  - Minimal Marketable Features (MMF)
  - Minimal Viable Product (MVP)
- Add working features and sets of features with each release
Release Planning
- Cadence-based (schedule-driven)
  - Advantages
    - Deliver functionality and business value earlier and more often
    - Predictable schedule
    - Predictable burn rate
    - Sustainable pace
  - Disadvantages
    - Must slice scope to fit schedule
    - Must use resources differently
  - Teams are more interdependent
- Scope-based (feature-driven)
  - Advantages
    - Discrete Statements of Work (SOWs)
    - Commodity oriented
  - Disadvantages
    - irregular delivery
    - delay in business value
    - resources may be used unevenly
  - Teams are more independent
User Stories
- Components
  - As a [role (who)]…
  - I want [feature (what)]…
  - So that [business value (why)]…
- Acceptance Criteria
  - help define done
  - manage expectations
  - lead to new requirements
  - attributes:
    - objective
    - measurable
    - testable
- Importance of components
  1. Why
  2. Who (personas)
  3. What
  4. Acceptance criteria
  5. How
- User Roles
  - How often do they use the system?
  - How technically savvy are they?
  - How much domain knowledge do they have?
  - What are their goals?
  - What are their pain points?
Grooming
- Progressive Elaboration
  - Higher-priority, sooner-to-be-completed items are smaller and better defined.
  - Lower-priority, farther-in-the-future items are larger and less defined
- Attributes of a good user story
  - Independent
  - Negotiable
  - Valuable
  - Estimatable
  - Small (no more than 1/2 sprint and only one of those)
  - Testable
- Dependencies for:
  - Business: Product Owner resolves
  - Technical: Dev Team Resolves
- Splitting User Stories
  - When to split stories
    - Split stories that are dependent on each other
    - Split stories that are too big
    - Split stories into spikes if complex or risky
    - Split compound Stories
  - How to split stories
    - Stories should represent some level of end-to-end functionality
    - Do not split into tasks like design/code/front/middle/back
    - Deliver cohesive subset of all layers
    - Do simplest thing that could work
    - Horizontal vs. Vertical
  - Patterns for splitting stories
    - Data boundaries
      - local vs. international
      - by credit card type
      - by currency type
    - Operational boundaries
      - CRUD
      - happy path vs. exceptional cases
      - business rules
    - Cross-cutting concerns
      - security
      - logging
      - error handling
    - Performance
    - Priority
      - necessity
      - flexibility
      - safety
      - comfort, luxury, performance
  - Development Approach: Iterate through…
    - core operations
    - capability, flexibility, safety
    - usability, performance, sizzle
  - Definition of Ready (for Dev Team to work on)
    - Defines when PBIs are ready for Dev Team to consume
    - Use INVEST as a guide
Estimation
- Context
  - Who provides the estimates?
  - Who commits to the estimates?
  - What units are used?
- Story Points
  - based on relative effort
  - based on volume of work, complexity, and risk
  - Fibonacci sequence?
- Planning Poker
  - all team members independently estimate
  - estimates are compared and outliers are discussed
  - consensus and understanding are reached
- Benefits
  - fast techniques
  - increases accuracy
  - builds understanding
  - drives commitment
  - provides data points
Sprint Planning
- Select highest business value stories
- Generate Sprint Backlog
- Determine what will be delivered
- Determine how it will be achieved
- Should take less than two hours per week of sprint
- Break PBIs into tasks and estimate
- End with Team’s forecast of what can be accomplished
- Task Board Columns (tasks per story by row, migrate tasks across)
  - Task
  - In-Progress
  - To Verify
  - Done
Sprint Review
- Dev Team presents Product Increment
- Product Owner, Stakeholders, SMEs review the increment and provide feedback
- Feedback is processed by Product Owner and used to adjust backlog and release plans

M	T	W	T	F	S	S
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31

Scrum Product Owner – Basic Outline

Leave a Reply Cancel reply

Recent Posts

Recent Comments

Categories

Meta