{"id":192,"date":"2015-12-14T21:08:27","date_gmt":"2015-12-15T03:08:27","guid":{"rendered":"http:\/\/rpchurchill.com\/?p=192"},"modified":"2016-03-24T10:54:44","modified_gmt":"2016-03-24T15:54:44","slug":"scrum-product-owner-basic-outline","status":"publish","type":"post","link":"https:\/\/rpchurchill.com\/wordpress\/posts\/2015\/12\/14\/scrum-product-owner-basic-outline\/","title":{"rendered":"Scrum Product Owner &#8211; Basic Outline"},"content":{"rendered":"<p>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.<\/p>\n<ul>\n<li><strong>Three Pillars of Scrum<\/strong>\n<ul>\n<li>Transparency<\/li>\n<li>Inspection<\/li>\n<li>Adaptation<\/li>\n<\/ul>\n<\/li>\n<li><strong>Iron Triangle (from Project Management)<\/strong>\n<ul>\n<li>Scope<\/li>\n<li>Cost<\/li>\n<li>Schedule (Time)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Scrum Ceremonies<\/strong>\n<ul>\n<li>Sprint Planning\n<ul>\n<li>all team members including Product Owner<\/li>\n<li>Dev Team commits to complete a negotiated amount of work from the highest-priority PBIs (Product Backlog Items)<\/li>\n<\/ul>\n<\/li>\n<li>Daily Scrum\n<ul>\n<li>Dev Team, ScrumMaster\n<ul>\n<li>What did I do yesterday?<\/li>\n<li>What am I going to do today?<\/li>\n<li>What impediments do I face?<\/li>\n<\/ul>\n<\/li>\n<li>presence of Product Owner can be very helpful to answer questions<\/li>\n<\/ul>\n<\/li>\n<li>Sprint Review\n<ul>\n<li>mainly review <em>what<\/em> was accomplished<\/li>\n<li>outside managers are encouraged to attend<\/li>\n<\/ul>\n<\/li>\n<li>Sprint Retrospective\n<ul>\n<li>mainly review the team&#8217;s <em>internal process<\/em><\/li>\n<li>mostly just for Dev Team and ScrumMaster<\/li>\n<\/ul>\n<\/li>\n<li>Product Backlog Refinement\n<ul>\n<li>Product Owner with Stakeholders, SMEs, Customers, Managers<\/li>\n<li>Also work with ScrumMaster, less with Dev Team<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Scrum Artifacts<\/strong>\n<ul>\n<li>Product Backlog<\/li>\n<li>Sprint Backlog<\/li>\n<li>Product Increment<\/li>\n<\/ul>\n<\/li>\n<li><strong>Product Owner Activities<\/strong>\n<ul>\n<li>Inward-Facing: Work with the Scrum Team\n<ul>\n<li>Release Planning<\/li>\n<li>Sprint Planning<\/li>\n<li>Daily Scrum<\/li>\n<li>Answer Questions<\/li>\n<li>Validate PBI (Product Backlog Item)<\/li>\n<li>Sprint Review<\/li>\n<\/ul>\n<\/li>\n<li>Outward-Facing: Work outside the Scrum Team\n<ul>\n<li>Work with SMEs, Stakeholders, and Customers<\/li>\n<li>Understands Needs<\/li>\n<li>Validate Product<\/li>\n<\/ul>\n<\/li>\n<li>Groom\/Refine Backlog\n<ul>\n<li>Create PBIs (Product Backlog Items)<\/li>\n<li>Split PBIs<\/li>\n<li>Reorder the Product Backlog<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Product Owner Responsibilities<\/strong>\n<ul>\n<li>Gathers input from stakeholders<\/li>\n<li>Establishes a high-level vision and goals<\/li>\n<li>Obtains a budget<\/li>\n<li>Identifies ways to improve business value<\/li>\n<li>Optimizes ROI<\/li>\n<li>Establishes clear release criteria<\/li>\n<li>Prioritizes the product backlog<\/li>\n<li>evolves the product backlog<\/li>\n<li>clarifies user stories<\/li>\n<li>maintains a release burndown chart<\/li>\n<\/ul>\n<\/li>\n<li><strong>Balance for Scrum Roles<\/strong>\n<ul>\n<li>Product Owner: Build the Right Thing<\/li>\n<li>Development Team: Build the Thing Right<\/li>\n<li>ScrumMaster: Build the Thing Effectively<\/li>\n<\/ul>\n<\/li>\n<li><strong>Levels of Planning (small -&gt; large)<\/strong>\n<ul>\n<li>Daily Planning<\/li>\n<li>Sprint Planning<\/li>\n<li>Release Planning<\/li>\n<li>Roadmap Planning<\/li>\n<li>Vision Planning<\/li>\n<\/ul>\n<\/li>\n<li><strong>Scrum Overview<\/strong>\n<ul>\n<li>Idea-&gt;Product Vision<\/li>\n<li>Roadmap\n<ul>\n<li>Initiation &#8211; Sprint 0<\/li>\n<li>Releases 1-n\n<ul>\n<li>Sprint 1\n<ul>\n<li>Sprint Plan<\/li>\n<li>Sprint (days)\n<ul>\n<li>Day 1<\/li>\n<li>Day &#8230;<\/li>\n<li>Day n<\/li>\n<\/ul>\n<\/li>\n<li>Sprint Review<\/li>\n<li>Sprint Retrospective<\/li>\n<li><em>Produces a Product Increment<\/em>\n<ul>\n<li>Meets Definition of Done<\/li>\n<li>Increment usable by customer<\/li>\n<li>Release (final)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Sprint n\n<ul>\n<li>Sprint Plan<\/li>\n<li>Sprint (days)\n<ul>\n<li>Day 1<\/li>\n<li>Day &#8230;<\/li>\n<li>Day n<\/li>\n<\/ul>\n<\/li>\n<li>Sprint Review<\/li>\n<li>Sprint Retrospective<\/li>\n<li><em>Produces a Product Increment<\/em>\n<ul>\n<li>Meets Definition of Done<\/li>\n<li>Increment usable by customer<\/li>\n<li>Release (final)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><em>Release Review<\/em><\/li>\n<li><em>Release Retrospective<\/em><\/li>\n<\/ul>\n<\/li>\n<li>Final Release<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Roadmapping<\/strong>\n<ul>\n<li>Start from core functionality\n<ul>\n<li>Minimal Marketable Features (MMF)<\/li>\n<li>Minimal Viable Product (MVP)<\/li>\n<\/ul>\n<\/li>\n<li>Add working features and sets of features with each release<\/li>\n<\/ul>\n<\/li>\n<li><strong>Release Planning<\/strong>\n<ul>\n<li>Cadence-based (schedule-driven)\n<ul>\n<li>Advantages\n<ul>\n<li>Deliver functionality and business value earlier and more often<\/li>\n<li>Predictable schedule<\/li>\n<li>Predictable burn rate<\/li>\n<li>Sustainable pace<\/li>\n<\/ul>\n<\/li>\n<li>Disadvantages\n<ul>\n<li>Must slice scope to fit schedule<\/li>\n<li>Must use resources differently<\/li>\n<\/ul>\n<\/li>\n<li>Teams are more <em>inter<\/em>dependent<\/li>\n<\/ul>\n<\/li>\n<li>Scope-based (feature-driven)\n<ul>\n<li>Advantages\n<ul>\n<li>Discrete Statements of Work (SOWs)<\/li>\n<li>Commodity oriented<\/li>\n<\/ul>\n<\/li>\n<li>Disadvantages\n<ul>\n<li>irregular delivery<\/li>\n<li>delay in business value<\/li>\n<li>resources may be used unevenly<\/li>\n<\/ul>\n<\/li>\n<li>Teams are more <em>in<\/em>dependent<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>User Stories<\/strong>\n<ul>\n<li>Components\n<ul>\n<li>As a [role (who)]&#8230;<\/li>\n<li>I want [feature (what)]&#8230;<\/li>\n<li>So that [business value (why)]&#8230;<\/li>\n<\/ul>\n<\/li>\n<li>Acceptance Criteria\n<ul>\n<li>help define <em>done<\/em><\/li>\n<li>manage expectations<\/li>\n<li>lead to new requirements<\/li>\n<li>attributes:\n<ul>\n<li>objective<\/li>\n<li>measurable<\/li>\n<li>testable<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Importance of components\n<ol>\n<li>Why<\/li>\n<li>Who (personas)<\/li>\n<li>What<\/li>\n<li>Acceptance criteria<\/li>\n<li>How<\/li>\n<\/ol>\n<\/li>\n<li>User Roles\n<ul>\n<li>How often do they use the system?<\/li>\n<li>How technically savvy are they?<\/li>\n<li>How much domain knowledge do they have?<\/li>\n<li>What are their goals?<\/li>\n<li>What are their pain points?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Grooming<\/strong>\n<ul>\n<li>Progressive Elaboration\n<ul>\n<li>Higher-priority, sooner-to-be-completed items are smaller and better defined.<\/li>\n<li>Lower-priority, farther-in-the-future items are larger and less defined<\/li>\n<\/ul>\n<\/li>\n<li>Attributes of a good user story\n<ul>\n<li><strong>I<\/strong>ndependent<\/li>\n<li><strong>N<\/strong>egotiable<\/li>\n<li><strong>V<\/strong>aluable<\/li>\n<li><strong>E<\/strong>stimatable<\/li>\n<li><strong>S<\/strong>mall (no more than 1\/2 sprint and only one of those)<\/li>\n<li><strong>T<\/strong>estable<\/li>\n<\/ul>\n<\/li>\n<li>Dependencies for:\n<ul>\n<li>Business: Product Owner resolves<\/li>\n<li>Technical: Dev Team Resolves<\/li>\n<\/ul>\n<\/li>\n<li>Splitting User Stories\n<ul>\n<li>When to split stories\n<ul>\n<li>Split stories that are dependent on each other<\/li>\n<li>Split stories that are too big<\/li>\n<li>Split stories into <a href=\"https:\/\/www.scrumalliance.org\/community\/articles\/2013\/march\/spikes-and-the-effort-to-grief-ratio\">spikes<\/a> if complex or risky<\/li>\n<li>Split compound Stories<\/li>\n<\/ul>\n<\/li>\n<li>How to split stories\n<ul>\n<li>Stories should represent some level of end-to-end functionality<\/li>\n<li>Do not split into tasks like design\/code\/front\/middle\/back<\/li>\n<li>Deliver cohesive subset of all layers<\/li>\n<li>Do simplest thing that could work<\/li>\n<li><a href=\"http:\/\/www.deltamatrix.com\/horizontal-and-vertical-user-stories-slicing-the-cake\">Horizontal vs. Vertical<\/a><\/li>\n<ul>\n<li><strong>Horizontal<\/strong>: layers or hardware or software functionality (e.g., database, I\/O, UI, security, user control, business rules, middleware, etc.)<\/li>\n<li><strong>Vertical<\/strong>: units of business functionality that cut across or incorporate functionality from horizontal system layers (e.g., user login and management, transaction processing, reporting, etc.)<\/li>\n<\/ul>\n<\/ul>\n<\/li>\n<li>Patterns for splitting stories\n<ul>\n<li>Data boundaries\n<ul>\n<li>local vs. international<\/li>\n<li>by credit card type<\/li>\n<li>by currency type<\/li>\n<\/ul>\n<\/li>\n<li>Operational boundaries\n<ul>\n<li>CRUD<\/li>\n<li>happy path vs. exceptional cases<\/li>\n<li>business rules<\/li>\n<\/ul>\n<\/li>\n<li>Cross-cutting concerns\n<ul>\n<li>security<\/li>\n<li>logging<\/li>\n<li>error handling<\/li>\n<\/ul>\n<\/li>\n<li>Performance<\/li>\n<li>Priority\n<ul>\n<li>necessity<\/li>\n<li>flexibility<\/li>\n<li>safety<\/li>\n<li>comfort, luxury, performance<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Development Approach: Iterate through&#8230;\n<ul>\n<li>core operations<\/li>\n<li>capability, flexibility, safety<\/li>\n<li>usability, performance, sizzle<\/li>\n<\/ul>\n<\/li>\n<li>Definition of Ready (for Dev Team to work on)\n<ul>\n<li>Defines when PBIs are ready for Dev Team to consume<\/li>\n<li>Use INVEST as a guide<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Estimation<\/strong>\n<ul>\n<li>Context\n<ul>\n<li>Who provides the estimates?<\/li>\n<li>Who commits to the estimates?<\/li>\n<li>What units are used?<\/li>\n<\/ul>\n<\/li>\n<li>Story Points\n<ul>\n<li>based on relative effort<\/li>\n<li>based on volume of work, complexity, and risk<\/li>\n<li>Fibonacci sequence?<\/li>\n<\/ul>\n<\/li>\n<li>Planning Poker\n<ul>\n<li>all team members independently estimate<\/li>\n<li>estimates are compared and outliers are discussed<\/li>\n<li>consensus and understanding are reached<\/li>\n<\/ul>\n<\/li>\n<li>Benefits\n<ul>\n<li>fast techniques<\/li>\n<li>increases accuracy<\/li>\n<li>builds understanding<\/li>\n<li>drives commitment<\/li>\n<li>provides data points<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Sprint Planning<\/strong>\n<ul>\n<li>Select highest business value stories<\/li>\n<li>Generate Sprint Backlog<\/li>\n<li>Determine what will be delivered<\/li>\n<li>Determine how it will be achieved<\/li>\n<li>Should take less than two hours per week of sprint<\/li>\n<li>Break PBIs into tasks and estimate<\/li>\n<li>End with Team&#8217;s forecast of what can be accomplished<\/li>\n<li>Task Board Columns (tasks per story by row, migrate tasks across)\n<ul>\n<li>Task<\/li>\n<li>In-Progress<\/li>\n<li>To Verify<\/li>\n<li>Done<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li><strong>Sprint Review<\/strong>\n<ul>\n<li>Dev Team presents Product Increment<\/li>\n<li>Product Owner, Stakeholders, SMEs review the increment and provide feedback<\/li>\n<li>Feedback is processed by Product Owner and used to adjust backlog and release plans<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>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 &hellip; <a href=\"https:\/\/rpchurchill.com\/wordpress\/posts\/2015\/12\/14\/scrum-product-owner-basic-outline\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[34,39,35],"_links":{"self":[{"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/posts\/192"}],"collection":[{"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/comments?post=192"}],"version-history":[{"count":7,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/posts\/192\/revisions"}],"predecessor-version":[{"id":531,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/posts\/192\/revisions\/531"}],"wp:attachment":[{"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/media?parent=192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/categories?post=192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rpchurchill.com\/wordpress\/wp-json\/wp\/v2\/tags?post=192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}