The role of the Product Owner in Scrum is only vaguely defined—owning the Product Backlog and representing the “customer.” In many organizations, Product Owners go it alone, trying their best to represent business needs to their teams. What’s often missing is a collaborative connection between the teams’ testers and the Product Owner—a connection in which testers help to define and refine requirements, broaden the testing landscape and align it to customer needs, provide a conduit for collaboration between the customer and the team, assure that the team is building the right thing, and help demonstrate complete features. This relationship is central to the team and facilitates transparency to help gain feedback from the entire organization. Join seasoned agile coach Bob Galen as he shares techniques for doing just this. Return 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
rent Session
Presented by:
Bob Galen Vel rs
Brought to you by:
340 Corporate Way, Suite Orange Park, FL 32073 888‐2
T7 Concur4/8/2014 12:45 PM
“A Tester’s Guide to Collaborating with Product Owners”
An agile methodologist, practitioner, and coach based in Cary, NC, Bob Galen helps guide companies in their adoption of Scrum and other agile methodologies and practices. Bob is a principal agile evangelist at Velocity Partners, a leading agile nearshore development partner; president of RGCG; and frequent speaker on software development, project management, software testing, and team leadership at conferences and professional groups. He is a Certified Scrum Coach, Certified Scrum Product Owner, and an active member of the Agile and Scrum Alliances. In 2013 Bob published Scrum Product Ownership–Balancing Value from the Inside Out. Reach him at [email protected].
Principle Agile Evangelist at Velocity Partnersp g g y
Somewhere ‘north’ of 30 years overall experience ☺Wide variety of technical stacks and business domainsDeveloper first, then Project Management / Leadership, then TestingSenior/Executive software development leadership for 20 yearsPracticing formal agility since 2000XP, Lean, Scrum, and Kanban experienceFrom Cary, North CarolinaConnect w/ me via LinkedIn and Twitter @bobgalen
Introduction1 Bridge stories1. Bridge stories2. Help write Acceptance Tests3. DoD accountability4. Be the customer5. Ask questions6. Triad everywhere7. Cost of quality8 C t f t ti
Verify that preferred members get 25% discount on extended servicesand reservation priority over other membersVerify that past Christmas customers get reservation priorityVerify that declines get email with discount coupon for future servicesVerify that sign-up process takes less than 4 minutes
6
#3, Hold everyone “accountable” to Definition of Done
It all starts in GroomingIt all starts in Grooming, thinking of the work cross-functionally and with DoD in mindContinue it in Sprint PlanningExecute consistently; no
Execute consistently; no exceptionsDeliver to “Done”
Ready-Ready
Prevents teams from taking on
The story is well-written; and has a minimum of 5 Acceptance Tests definedThe story has been sized to fit the teams velocity & sprint length: 1-13 pointstaking on
stories that are ill
groomed or defined
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 implicationsThe story is not “too complete”, around ~70% completeThe team understands how to approach the testing of the stories’ functional and non-functional aspectsAny dependencies to other stories and/or teams have been “connected” so that the story is synchronized and
Increases sprint success
been connected so that the story is synchronized and deliverableThe story aligns with the Sprints’ Goal and is end-to-end demonstrableIf a “Technical Story” the story has a “Technical PO” to provide guidance and sign-off