Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A Testers Guide To Collaborating With Product Owners

893 views

Published on

In Scrum the Product Owner is relatively starkly defined. They are the owner of the Product Backlog and represent the “customer”. In many organizations, they “go it alone”, trying their best to represent business needs for their teams. What’s often missing in this approach is a wonderful collaborative connection between the teams’ testers and the Product Owner.

A connection where testers help to define and refine requirements, broaden the testing landscape and align it to customer needs, provide a collaborate conduit between the customer and the team, assure that the team is building the “right thing”, and helping to demonstrate complete features . This relationship is not only central to the team, but facilitates transparency and helps gain feedback from the entire organization. Join seasoned agile coach Bob Galen as he shares stories and techniques for doing just this. You will return to your agile teams with new ideas and techniques for helping your Product Owner and team deliver better received and higher value products; not just by “testing”, but by “fostering collaboration”.

Published in: Technology
  • Be the first to comment

A Testers Guide To Collaborating With Product Owners

  1. 1. A Tester’s Guide to Collaborating with Product Owners 10 Keys to Delivering Value Bob Galen President & Principal Consultant RGCG, LLC bob@rgalen.com
  2. 2. Copyright © 2015 RGCG, LLC Introduction Bob Galen n  Independent Agile Coach (CSC) at RGCG, LLC n  Principle Agile Evangelist at Velocity Partners n  Somewhere ‘north’ of 30 years overall experience J n  Wide variety of technical stacks and business domains n  Developer first, then Project Management / Leadership, then Testing n  Senior/Executive software development leadership for 20 years n  Practicing formal agility since 2000 n  XP, Lean, Scrum, and Kanban experience n  From Cary, North Carolina n  Connect w/ me via LinkedIn and Twitter @bobgalen Bias Disclaimer: Agile is THE BEST Methodology for Software Development… However, NOT a Silver Bullet!
  3. 3. Copyright © 2015 RGCG, LLC
  4. 4. Copyright © 2015 RGCG, LLC Outline – Myths & Realities Introduction 1.  Bridge stories 2.  Help write Acceptance Tests 3.  DoD accountability 4.  Be the customer 5.  Ask questions 6.  Cost of quality 7.  Cost of testing 8.  Backlog as a “plan” 9.  Take the PO to lunch
  5. 5. Copyright © 2015 RGCG, LLC 5 Simple pattern: The Product Owner ‘Owns’ the Product Backlog Essential pattern It Takes a Village to ‘Own’ the Backlog Who owns the Backlog?
  6. 6. 4 Quadrants of Product Ownership 1.  Product Manager q  Product Roadmap, Collateral, Business Case / ROI q  Driving customer value 2.  Project Manager q  Product Backlog (WBS) q  Grooming & look-ahead q  Velocity-based, Release Planning q  Goal setting, Budget 3.  Leader q  Trade-offs, product balance q  Stakeholder “management” q  Member of the team; partner with the Scrum Master 4.  Business Analyst q  Story writing q  Acceptance q  Emergence; Spikes Copyright © 2015 RGCG, LLC
  7. 7. Copyright © 2015 RGCG, LLC #1, Bridge stories from Team to the Product Owner n  The key here is guiding the translation and execution of the user story q  Pull the Product Owner into the sprint q  Show incremental code q  Shepherd sign-off n  3 Amigos-based interactions n  Nail the Demo
  8. 8. Copyright © 2015 RGCG, LLC #1, Bridge stories from Team to the Product Owner n  Coined by George Dinwiddie n  Swarming around the User Story by: q  Developer(s) q  Tester(s) q  Product Owner n  During “Grooming, Sprint Execution, Until…”Done” n  Similar to Ken Pugh’s - Triad
  9. 9. Copyright © 2015 RGCG, LLC #2, Help write solid Acceptance Tests n  Consider them q  as “mini-contracts” or “mini- UAT” n  3-5 minimal per story n  Business constraints n  Functional and non- functional n  Edge and error cases n  Provide hints: q  Design & Test
  10. 10. Copyright © 2015 RGCG, LLC #2, Help write solid Acceptance Tests 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 Verify that sign-up process takes less than 4 minutes
  11. 11. Copyright © 2015 RGCG, LLC #3, Hold everyone “accountable” to Definition of Done n  It all starts in Grooming, thinking of the work cross-functionally and with DoD in mind n  Continue it in Sprint Planning n  Execute consistently; no exceptions n  Deliver to “Done”
  12. 12. Copyright © 2015 RGCG, LLC 4-Levels of Criteria Activity Criteria Example Basic Team Work Products Done’ness criteria Pairing or pair inspections of code prior to check-in; or development, execution and passing of unit tests. User Story or Theme Level Acceptance 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. Sprint or Iteration Level Done’ness criteria Defining a Sprint Goal that clarifies the feature development and all external dependencies associcated with a sprint. Release Level Release criteria 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.
  13. 13. Ready-Ready Prevents teams from taking on stories that are ill groomed or defined Increases sprint success ü  The story is well-written; and has a minimum of 5 Acceptance Tests defined ü  The story has been sized to fit the teams velocity & sprint length: 1-13 points ü  The team has vetted the story in several grooming sessions—it’s scope & nature is well understood ü  If required, the story had a research-spike to explore (and refine) it’s architecture and design implications ü  The story is not “too complete”, around ~70% complete ü  The team understands how to approach the testing of the stories’ functional and non-functional aspects ü  Any dependencies to other stories and/or teams have been “connected” so that the story is synchronized and deliverable ü  The story aligns with the Sprints’ Goal and is end-to-end demonstrable ü  If a “Technical Story” the story has a “Technical PO” to provide guidance and sign-off Copyright © 2015 RGCG, LLC
  14. 14. Copyright © 2015 RGCG, LLC #4, Represent the Customer n  Don’t solve “requirements”…solve “customer problems” n  Consider usage n  KISS n  Deliver value; highest impact & priority n  End-to-end solutions
  15. 15. Copyright © 2015 RGCG, LLC #4, Represent the Customer n  The power of a Minimal Marketable Feature n  The power of the Persona n  Observe the Customer n  Nordstrom Innovation Lab: http://www.youtube.com/ watch?v=szr0ezLyQHY
  16. 16. Copyright © 2015 RGCG, LLC #5, Ask questions? Be inquisitive, be curious, explore! n  Ask questions q  Relentlessly, Constantly, Courageously n  5 – Whys n  Business value? n  Lean investment q  Just enough and just-in- time n  Trust your instincts, craft n  Does it make sense?
  17. 17. Copyright © 2015 RGCG, LLC #5, Ask questions? Be inquisitive?
  18. 18. Copyright © 2015 RGCG, LLC #6, What about the Cost of Quality? n  Meta-requirements q  Security, Performance, Maintainability n  Automation investments q  Agile Automation Triangle n  Inspections – pairing n  DoD maturity n  Avoid rework? q  Yes for product, no for experiments Quality is a TEAM responsibility!
  19. 19. A Tapestry that Includes Threads for… Things to do… n  Features n  Value increments n  Architecture n  Design n  Process n  Quality n  Testing In a Context-Based fashion… n  Deployment n  Regulatory n  Dependency n  Risk n  Feedback n  Customer timing n  Tempo …Guiding us towards customer value Copyright © 2015 RGCG, LLC 19
  20. 20. Copyright © 2015 RGCG, LLC #7, What about the Cost of Testing? n  Risk-based n  Always test what’s available n  Don’t track coverage or time n  Slack time for thinking & creativity n  Balanced across the quadrants
  21. 21. 3-Pillars of Agile Quality & Testing Thank you! Copyright © 2015 RGCG, LLC and governance sit, and where broad reporting is performed. I am NOT talking about traditional testing with all of its process focus “testers”, but of everyone on the team. I still find far too many agil teamsthatrelegatetheownershipofqualityandtestingonlytotesters Pyramid-based Strategy: (Unit + Cucumber + Selenium) Continuous Integration Attack technical infrastructure in the Backlog Visual Feedback – Dashboards Actively practice ATDD and BDD Whole Team Ownership of “Quality” Knowing the Right Thing to Build; And Building it Right Healthy – Agile Centric Metrics Steering via: Center of Excellence or Community of Practice Strategic balance across 3 Pillars; Assessment, Recalibration, and Continuous Improvement Risk-based testing: Functional & Non-Functional Test planning @ Release & Sprint levels Exploratory Testing Standards – checklists, templates, repositories Balance across manual, exploratory & automation Team-based Pairing Stop-the-Line Mindset Code Reviews & Standards Active Done-Ness Aggressive Refactoring of Technical Debt User Stories, “3 Amigo” based Conversations Software Testing Cross-Functional Team Practices Development & Test Automation Pillars of Agile Quality Figure 1. High-level View of the Three Pillars
  22. 22. Copyright © 2015 RGCG, LLC #8, The Backlog is a “Plan” help focus it towards Release! n  Ask for and define a Release Train n  Encourage Release Planning n  Establish “hardening” activities n  Integration milestones – working code
  23. 23. Copyright © 2015 RGCG, LLC Release Train Management n  Iterative model with a release target q  Product centric q  Focused on a production push/ release n  Synchronized Sprints across teams q  Some teams are un- synchronized, but leads to less efficient cross-team (product) interactions n  Continuous Integration is the glue q  Including automated unit and feature tests; partial regression n  Notion of a “Hardening Sprint” q  Focused more on Integration & Regression testing q  Assumption that it’s mostly automated q  Environment promotion n  Define a final Hardening Sprint where the product is readied for release q  Documentation, Support, Compliance, UAT, Training
  24. 24. Copyright © 2015 RGCG, LLC #9, Get to know your Product Owner n  Have lunch n  Discuss the competitive landscape, the Market n  Customer challenges n  MoSCoW in operation n  Commitments & Pressure n  Vision & Mission; what does “success” look like?
  25. 25. #10 - Wrapping up… Helping the Product Owner to build the “Right Thing” And Helping the Team to build “Things Right” Copyright © 2015 RGCG, LLC
  26. 26. Copyright © 2015 RGCG, LLC Wrap-up n  Get a free copy of my 3-Pillars book by joining my RGCG mailing list at: – http://goo.gl/3SFQci Thank you! 26

×