Demystifying the Role of Product Owner


Published on

Have you ever wondered what makes a good Product Owner? It’s a broad and deep role that is often filled with a hodgepodge of differently skilled individuals. Many organizations struggle to understand its importance as they scale their agile transformations. What about exceptional Product Ownership? What does that entail? In this highly collaborative session, Bob Galen explores the Four Quadrants of Effective Product Ownership—Product Management, Project Management, Leadership, and Business Analysis. Each of these critical aspects of the Product Owner role supports the agile team. Together, they lead to well-constructed product backlogs with an emphasis on creating high quality and high value products. Leave this session with a better understanding of the breadth and depth associated with outstanding Product Owners, a newfound respect for how challenging the role is, and with immediate insights and actions for improving your organization’s Product Ownership.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Demystifying the Role of Product Owner

  1. 1.   AT12 Concurrent Session  11/14/2013 3:45 PM            "Demystifying the Role of Product Owner"       Presented by: Bob Galen RGalen Counsulting Group, LLC                   Brought to you by:        340 Corporate Way, Suite 300, Orange Park, FL 32073  888‐268‐8770 ∙ 904‐278‐0524 ∙ ∙
  2. 2. Bob Galen RGalen Consulting Bob Galen is an agile coach at RGalen Consulting and director of agile solutions at Zenergy Technologies, a North Carolina-based firm specializing in agile testing and leading agile adoption initiatives. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing, and team leadership. He is a Certified Scrum Master Practicing, Certified Scrum Product Owner, and an active member of the Agile Alliance and Scrum Alliance. Bob published Scrum Product Ownership: Balancing Value from the Inside Out, which addresses the gap in guidance toward effective agile product management. Contact Bob at or
  3. 3. Demystifying the Product Owner Role Bob Galen President & Principal Consultant RGCG, LLC Introduction Bob Galen n  n  n  n  n  n  n  n  Somewhere ‘north’ of 30 years experience J Various lifecycles – Waterfall variants, RUP, Agile, Chaos… Various domains – SaaS, Medical, Financial Services, Computer & Storage Systems, eCommerce, and Telecommunications Developer first, then Project Management / Leadership, then Testing Leveraged ‘pieces’ of Scrum in late 90’s; before ‘agile’ was ‘Agile’ Agility @ Lucent in 2000 – 2001 using Extreme Programming Formally using Scrum since 2000 Currently an independent Agile Coach (CSC – Certified Scrum Coach, one of 50 world-wide; 20+ in North America) q  n  n  at RGCG, LLC and Director of Agile Solutions at Zenergy Technologies From Cary, North Carolina Connect w/ me via LinkedIn and Twitter if you wish… Bias Disclaimer: Agile is THE BEST Methodology for Software Development… However, NOT a Silver Bullet! Copyright © 2013 RGCG, LLC 4 1
  4. 4. Outline n  n  n  n  n  n  Introduction Role of the “Product Owner” Product Backlogs Sprint Dynamics Goals & Criteria Role of the Product Owner at-Scale Q&A Copyright © 2013 RGCG, LLC 5 The SCRUM Framework Copyright © 2013 RGCG, LLC 6 2
  5. 5. Roles in the SCRUM Framework Lets get the team together and figure this out! Our burn-down is off, what’s going on? How do I drive value? Team Member n  Product Owner •  •  •  •  Contributes to Product Backlog and Goals Prioritizes the backlog Typically a product manager Accepts the teams’ work n  n  n  n  n  Cross-functional role: QA + Dev + Doc + Arch. + etc. 7 +/- 2 in size Teams are self-organizing Focused teams Members should be fulltime co-located whenever possible Scrum Master •  •  •  Scrum PM like role Responsible for enacting Scrum values and practices Main job is to remove impediments Copyright © 2013 RGCG, LLC 7 Inside Out? n  Many Product Owners are conflicted… q  q  q  q  Training Overloaded Time allowed Domain & Customer familiarity n  Serious role within Scrum and should be handled that way n  Premise: Product Owners first responsibility is towards their Team! ü  ü  ü  ü  Backlog & work orchestration Interaction & feedback Goal setting & acceptance Leadership & partnership Copyright © 2013 RGCG, LLC 8 3
  6. 6. 4 Quadrants of Product Ownership 1.  Product Manager q  q  2.  Project Manager q  q  q  q  3.  Leader Product Roadmap, Collateral, Business Case / ROI Driving customer value Product Backlog (WBS) Grooming & look-ahead Velocity-based, Release Planning Goal setting, Budget q  q  q  Trade-offs, product balance Stakeholder “management” Member of the team; partner with the Scrum Master 4.  Business Analyst q  q  q  Story writing Acceptance Emergence; Spikes Copyright © 2013 RGCG, LLC 9 Scrum Guide Product Owner Definition The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: q  q  q  q  q  Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Ensuring the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands Copyright © 2013 RGCG, LLC 10 4
  7. 7. Scrum Guide Product Owner Definition The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable. For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says. Scrum Guide, October 2011 version, except from page 5 Copyright © 2013 RGCG, LLC 11 Scrum Guide Scrum Master Service to the Product Owner The Scrum Master serves the Product Owner in several ways, including: q  q  q  q  q  q  Finding techniques for effective Product Backlog management; Clearly communicating vision, goals, and Product Backlog items to the Development Team; Teaching the Scrum Team to create clear and concise Product Backlog items; Understanding long-term product planning in an empirical environment; Understanding and practicing agility; and, Facilitating Scrum events as requested or needed. Scrum Guide, October 2011 version, except from page 7 Copyright © 2013 RGCG, LLC 12 5
  8. 8. Agile Atlas (Scrum Alliance) Definition The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date. This is done by managing the flow of work into the team, selecting and refining items from the Product Backlog. The Product Owner maintains the Product Backlog and ensures that everyone knows what is on it and what the priorities are. The Product Owner may be supported by other individuals but must be a single person. Certainly the Product Owner is not solely responsible for everything. The whole Scrum Team is responsible for being as productive as possible, for improving their practices, for asking the right questions, for helping the Product Owner, and so on. The Development Team is responsible for determining how much work will be taken on in a Sprint, and for producing a usable Product Increment in every Sprint. Copyright © 2013 RGCG, LLC 13 Agile Atlas (Scrum Alliance) Definition n  Nonetheless, the Product Owner, in Scrum, is in a unique position. The Product Owner is typically the individual closest to the "business side" of the project. The Product Owner is typically charged by the organization to "get this product out", and is typically the person who is expected to do the best possible job of satisfying all the stakeholders. The Product Owner does this by managing the Product Backlog, and by ensuring that the Product Backlog, and progress against it, is kept visible. n  The Product Owner, by choosing what the Development Team should do next and what to defer, makes the scope versus schedule decisions to lead to the best possible product. - September 2013 Copyright © 2013 RGCG, LLC 14 6
  9. 9. Community Disagreement over the Role n  Single individual or collaborative group? q  n  Scrum Yahoo Group there was discussion in the Fall of 2008 regarding whether it could be done by a small group. Schwaber stated that “there can be only 1”. Oh, and are they a part of the team? q  q  q  Scrum team vs. Development team For example, do they attend the Sprint Retrospectives? Can they perform work within the Sprint? Copyright © 2013 RGCG, LLC The Product Owner Is… n  n  Provides the Product Vision – where the team “going”; shares the voice of the customer (VOC) n  Needed to be available daily for work feedback, acceptance, and scope adjustment discussions n  Communicates externally to Stakeholders and buffers the team from potential distractions n  Accountable for the teams results meeting business expectations The primary “keeper” of the teams’ Product Backlog q  q  n  15 Required to provide a balanced and nuanced Product Backlog A writer of requirements that are well defined, granular, and most importantly testable Is responsible for considering the capability of their team (skills, strengths, weaknesses, #’s, etc.) and setting the Backlog to amplify successful execution Copyright © 2013 RGCG, LLC 16 7
  10. 10. The Product Owner Is not… n  The manager of the team; nor responsible for performance management. They can give performance feedback, but only when requested to do so. This is the Functional Managers responsibility n  A decider of technical direction (architecture, design, etc.), that is the Teams responsibility n  A contributor to Story or Task estimates; that is the Teams responsibility n  Responsible for the overall skill of the team; selecting team members; or fighting for individuals. The Functional Managers tries to effectively balance the teams Copyright © 2013 RGCG, LLC 17 Product Owner role according to Roman Pichler n  n  n  n  n  n  n  n  n  n  Product Vision Product Business Model (value & benefit) Product Roadmap Planning Collaborate with the Scrum Master and Development team Describe UX and Features Determine Goals (Sprint) Research / Validation for Feedback (effective Reviews, etc.) Review Feedback & Adjust – Feature(s) and Roadmap Look after the Budget Coordinate Launch Copyright © 2013 RGCG. LLC 18 8
  11. 11. Ownership/Role Balance n  Product Owner owns: What n  Team Owns: How and How n  Long Scrum Master owns: Agile Principles & Practices Challenge & discuss – Yes; but in the end, TRUST the ROLES! Copyright © 2013 RGCG, LLC 19 Product Backlogs Copyright © 2013 RGCG, LLC 20 9
  12. 12. Product Backlog Simple list, or something else? n  All work vs. feature work? One list vs. many? q  q  n  Features, Technical, Quality, Release, etc. Excel Product Backlog Items (PBIs) vs. User Stories vs. something else altogether? Connecting to other artifacts? How do you orchestrate or influence – Emergent Practices? q  q  q  Not writing Too Much…Too Soon Architecture, feature sets, usability, design, etc. Balancing look-ahead? Copyright © 2013 RGCG, LLC 21 Where do User Stories “Come From”? n  Stories come from: q  q  q  n  Customer wants/needs; bugs, maintenance, technical debt Product Owner capturing individual stories; team members User Story Writing Workshops Who writes them? q  q  q  Initially – the Product Owner or individual team members Eventually – everyone “touches” them via Backlog Grooming It Takes a Village! Copyright © 2013 RGCG, LLC 22 10
  13. 13. Product Backlog as… WBS? n  Partitioning the Backlog - workflow q  q  q  n  n  n  n  n  Opening Moves – emergent understanding, beginning well Middle Game – stabilization, value, mass End Game – integration, quality, customer delivery Design or look-ahead activity Features Dependencies & X-team hand-offs Iterations & Milestones Transparency & “progress tracking” Copyright © 2013 RGCG, LLC 23 Iceberg Model Copyright © 2013 RGCG, LLC 24 11
  14. 14. Backlog ‘Tension’ Points n  n  n  How many items? Size – does it matter? Are they all the same? Prioritization & Valuation methods? FutureCast – painting a compelling picture of the “Tactical Now” vs. the “Strategic Later” w/o scaring everyone to death… Granularity heuristic Use the 20/30/50 rule. 20% proper stories ready to roll. 30% are epics bigger stories that will eventually be split out into smaller fine grained ones (only as needed). The last 50% are themes - vague ideas about long term product direction and I never put much effort here because it’s almost always wrong. Copyright © 2013 RGCG, LLC 25 Grooming your Backlogs Approaches? n  The Product Backlog is Organic and needs care & feeding q  q  n  Reserve time for collaborative, team-based grooming meetings OR ‘Assign’ individual stories to team members Combination of these two Keeping it interesting, grooming at 3 levels: q  q  q  20%: what’s right around the corner – are we ready? 30%: what’s 3-4 sprints away – are we getting clearer? 50%: what’s the future looking like? Break those things down… Copyright © 2013 RGCG, LLC 26 12
  15. 15. Grooming your Backlogs Look-ahead n  Judicious use of Research Spikes to gain understanding; output of a Spike: q  Knowledge, solid stories, prototype code, design(s), tooling, etc. n  In some cases, run Iteration #0 types of exploratory iterations to get broad information under your feet n  Always looking for new ‘contributions’ q  q  Technical, quality, release workflow, etc. Rarely do they seem to be forthcoming; encourage them from the team Copyright © 2013 RGCG, LLC 27 Active Backlog Grooming n  n  n  n  n  n  n  Bring goals & stories to the table; but be open to change Listen actively Don’t predetermine size nor complexity; trust your team Don’t negotiate…collaborate Organic explorations of scope and options as you get closer to execution Explore execution dynamics – architecture & design, testing, non-functional, deployment, and risk Apply pressure on – value flow, quality & sustainable pace Copyright © 2013 RGCG, LLC 28 13
  16. 16. A Tapestry that Includes Threads for… Things to do… n  n  n  n  n  n  n  Features Value increments Architecture Design Process Quality Testing In a Context-Based fashion… n  n  n  n  n  n  n  Deployment Regulatory Dependency Risk Feedback Customer timing Tempo …Guiding us towards customer value Copyright © 2013 RGCG, LLC 29 User Stories Hierarchical Types n  Epic – a huge idea, spanning multiple teams and multiple sprints. Could be several releases. Rarely well understood. n  Theme – a large idea; spanning multiple teams, but normally fitting into a release. Normally a simple marketing container – for planning & prioritization. n  Feature – a large idea; spanning multiple teams, always fitting into a release. Assigned team owner. n  User Stories – work items for a given sprint. Well understood. All work delivered in story-units. Copyright © 2013 RGCG, LLC 30 14
  17. 17. User Stories Hierarchical Types Hierarchy Epic Theme or Feature Story Attributes Visited •  •  •  Defer planning precision - Visioning •  Container, X-teams Roadmap & Portfolio Level Planning Annually, phased planning, roadmap forecasts •  •  Container, potentially X-teams Release Level Planning (1-2 releases ahead) High Level Research – Feature Spike •  Quarterly to monthly Track feature delivery Team work item Can be quite large (13 – 20 points) Sprint Planning Low Level Spikes •  •  •  •  •  •  •  •  Monthly to Sprintly Track story delivery Copyright © 2013 RGCG, LLC 31 Product Backlog Wall Source: Copyright © 2013 RGCG, LLC 32 15
  18. 18. Sprinting Copyright © 2013 RGCG, LLC 33 Sprint Dynamics Planning n  Always be ready; strategize with your Scrum Master q  q  q  No surprises for the team! You’re part of the team, stay engaged in the entire process Drive everything with ‘goals’ Point of Sprint Planning 1.  2.  To share and gain the teams’ commitment toward the Sprint Goal To identify the set of User Stories that align with and are feasible to deliver within the Sprint 3.  To identify the Tasks associated with delivering those User Stories In that priority order and leading to goal-driven work Copyright © 2013 RGCG, LLC 34 16
  19. 19. Remember -- The Triad Customer Collaboration FIRST… Automation SECOND… Ken Pugh has written a book on ATDD and uses the “Triad” to amplify this collaborative pairing between roles…Product Owner is central to that! Collaboration Developer Copyright © 2013 RGCG, LLC Tester 35 Sprint Dynamics Execution n  Stay engaged q  q  q  n  Looking-ahead q  q  n  Attend daily Scrum Observe the trending; consider adjustments as the sprint evolves Actively participate…perhaps in testing; certainly in grooming Grooming the Backlog in ALL dimensions Collaborating with Customers & Stakeholders Observe & understand your team dynamics q  Strengths, capabilities, weaknesses, etc. Copyright © 2013 RGCG, LLC 36 17
  20. 20. Sprint Dynamics Execution The very next day, the Product Owner gave me a call. Again, 5 a.m. on the west coast, but hey… he had a Sprint progress observation and wanted my advice. He said it seemed clear that the team was going to miss delivering some of the features for the Sprint. However, he was OK with that and wanted to know if he could start removing or reframing Stories in order to increase the teams ability to meet the Sprint Goal? So, here’s a Product Owner who, in their very first Sprint, gets the difference between planned scope versus actual team capacity and the need for ongoing adjustments. Ah Ha—I thought! Copyright © 2013 RGCG, LLC 37 Sprint Review A Defining Moment n  Take ownership of attendance q  q  q  n  Ensure key stakeholders are going to attend; If not, ask them to send someone Make it compelling to them; sell the opportunity Same ‘ceremony’ every Sprint? Help the team prepare q  q  q  Have a ‘script’; don’t over-prepare, but DO NOT wing it Product Owners should “Set the Stage” for the Sprint It’s not simply about features n  q  Other artifacts, test automation, prototypes, etc. Whole team approach Copyright © 2013 RGCG, LLC 38 18
  21. 21. Sprint Review A Defining Moment n  Serve as the M/C of the review q  q  n  Call it! At a Story level and at a Sprint level… q  n  Ensure clarity of communication Pace & transitions Pass or Fail? Connect the dots q  q  q  Relative to challenges in the sprint Relative to release goals Relative to customer expectations Copyright © 2013 RGCG, LLC 39 Review Flow §  Organized & Thoughtful Flow q  q  q  q  q  q  q  q  q  Introduction Team Chart Acknowledgements - Appreciations Sprint Goal Strategy? Success? Efforts? Discoveries? Results? Demo’s; Q&A Coming Attractions Fist-of-Five Towards Improvement Close Copyright © 2013 RGCG, LLC 40 19
  22. 22. Sprint Retrospective n  And as a member of the team… Attend the retrospective q  q  q  q  q  Actively participate Bring in an outside “business perspective” It’s ok to share your pressures Quality impressions; Continuous Improvement impressions Focus on Predictability, Quality, and Value Copyright © 2013 RGCG, LLC 41 Goals Copyright © 2013 RGCG, LLC 42 20
  23. 23. Leading with Goal Setting ü  Release Goals ü  Sprint Goals ü  Feature Acceptance n  n  n  n  Over Features, Stories, and Tasks Value-driven Envisioning Chartering Copyright © 2013 RGCG, LLC 43 Establishing Goals & Criteria Why it’s Crucial? n  Agile teams are essentially self-directed, so plans don’t drive behavior or success… n  People do and Goals drive the Team! n  The team then swarm around the goal(s), using their creativity and teamwork to figure out: q  q  q  What’s most important How to achieve it Always looking for simple & creative—20% solutions Copyright © 2013 RGCG, LLC 44 21
  24. 24. Notions of Done-ness n  n  Need to define “Done” from team members perspectives If you’re a developer, what does “I’m done with that story” mean? ü  ü  ü  ü  ü  ü  ü  n  Code complete Code reviewed (paired) Checked in – build successful Unit tests developed – passed Integration QA collaboration Run by the Product Owner Every type of task should have a definition of done-ness! How else could you estimate the work? Copyright © 2013 RGCG, LLC 45 Story Acceptance n  Each User Story should have acceptance criteria as part of the card n  They should focus on the verifiable behavior, business logic, for the story n  Typically, they are crafted by the Product Owner q  n  Leveraging skills of Business Analysts and Testers Story acceptance tests are normally automated and run as part of feature acceptance AND regression Copyright © 2013 RGCG, LLC 46 22
  25. 25. User Story Examples As a dog owner, I want to sign-up for a kennel reservation over Christmas so that I get a confirmed spot Verify individual as a registered pet owner Verify that preferred members get 15% discount on basic service Verify that preferred members get 25% discount on extended services and reservation priority over other members Verify that past Christmas customers get reservation priority Verify that declines get email with discount coupon for future services Copyright © 2013 RGCG, LLC 47 Iteration / Goal Acceptance n  Each Scrum Sprint has a Product Owner determined Sprint Goal n  Usually sprint success is not determined by the exact number of completed stories or tasks n  Instead, what most important is meeting the spirit of the goal Deliver a 6 minute demonstration of the software that demonstrates our most compelling value features and achieves venture capital investment interest Copyright © 2013 RGCG, LLC 48 23
  26. 26. Release Criteria n  n  Goals and objectives for the entire project release Usually they are multi-faceted, defining a broad set of conditions q  q  q  q  q  q  n  Required artifacts Testing activities or coverage levels Quality or allowed defect levels Results or performance metrics achievement levels Collaboration with other groups Compliance levels That IF MET would mean the release could occur. Copyright © 2013 RGCG, LLC 49 Levels of Criteria Activity Criteria Basic Team Work Products Done’ness criteria User Story or Theme Level Acceptance Tests Sprint or Iteration Level Done’ness criteria Release Level Release criteria Example Pairing or pair inspections of code prior to check-in; or development, execution and passing of unit tests. Development of FitNesse based acceptance tests with the customer AND their successful execution and passing. Developed toward individual stories and/or themes for sets of stories. Defining a Sprint Goal that clarifies the feature development and all external dependencies associcated with a sprint. Defining a broad set of conditions (artifacts, testing activities or coverage levels, results/metrics, collaboration with other groups, meeting compliance levels, etc.) that IF MET would mean the release could occur. Contributed to Chapter 20 of Lisa Crispin & Janet Gregory’s new 2009 Agile Testing book Copyright © 2013 RGCG, LLC 50 24
  27. 27. Who Decides on Quality? n  Of Course, Quality isn’t a simple pattern, it’s a façade n  Jim Coplien responding to a point on Scrum Alliance leadership list (paraphrased)… Value doesn’t matter when examining technical debt. Rather, that cleaning up after yourself transcended the normal determination of business value and was simply an inherent part of delivering software. That it is our responsibility and is non-negotiable. The decision-making wasn’t FOR the business-side, but instead resides within the team. n  n  Listen to your team! Ask the ‘Right’ questions! Copyright © 2013 RGCG, LLC 51 Role of the Product Owner At Scale Copyright © 2013 RGCG, LLC 53 25
  28. 28. Chartering Chartering Components q  q  q  q  q  q  q  q  Project visioning Shared stakeholder expectations Goals & Success criteria Approaches, Process, Methods Team, Communication, Metrics Scope & Budget Risk handling Sign-off Agile Practices q  q  q  q  q  q  Road-mapping Backlog grooming, Story writing Collaborative release planning Crystal – Blitz Planning Patton – Story-Mapping XP – Planning Game Copyright © 2013 RGCG, LLC 54 Product Management n  Facilitating high level visioning q  q  n  n  n  Competitive landscape Technology and corporate direction Chartering of new projects Product Road-maps & release orchestration Story development q  q  q  Epic -> Feature (MMF) -> Story stream Priority & value Technical clarity (quality, architecture, technical debt) Copyright © 2013 RGCG, LLC 55 26
  29. 29. Portfolio Management n  Something similar to the Lean Dog – Big Visible Room for executives to q  n Instead of an electronic dashboard, q  q  q  q  Vision, Portfolio, Assignments, Value, ROI Release plans, application funnel Capability and competency Agile practices / team alignment Copyright © 2013 RGCG, LLC 56 Scrum of Scrums n  n  Periodic meeting – similar to daily stand-up Focus: q  q  q  q  n  X-team interactions, dependencies, and blocks Release planning & communication Frequency dictated by state Information radiators: release burndown, impediments, etc. Key reference q Copyright © 2013 RGCG, LLC 57 27
  30. 30. Scrum of Scrums board Story + Status (across teams) Source: Copyright © 2013 RGCG, LLC 58 In Closing… n  Product Ownership (by the Customer, Stakeholder, BA, Product Manager) is the most crucial role within agile teams, providing— ü  ü  ü  ü  ü  ü  Inspirational vision Clear goal – setting; quality balanced Prioritized requirements – value based, workflow Measured & accepted results Scaled appropriately Focus towards the team first Copyright © 2013 RGCG, LLC 67 28
  31. 31. Wrap-up •  What were the most compelling ideas, stories, or lessons? What adjustments will you make in your Product Ownership? What ideas did I miss? •  Final questions or discussion? •  •  Thank you! Copyright © 2013 RGCG, LLC 68 Contact Info Bob Galen Principal Consultant, RGalen Consulting Group, L.L.C. Experience-driven agile focused training, coaching & consulting Contact: (919) 272-0719 Blogs Project Times - BA Times - Podcast on all things ‘agile’ - Copyright © 2013 RGCG, LLC 69 29