A Testers Guide To Collaborating With Product Owners

A Tester’s Guide to Collaborating
with Product Owners
10 Keys to Delivering Value
Bob Galen
President & Principal Consultant
RGCG, LLC
bob@rgalen.com

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!

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

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?

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

#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

#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

#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

#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

#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”

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.

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

#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

#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

#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?

#5, Ask questions?
Be inquisitive?

#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!

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

#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

3-Pillars of Agile Quality & Testing
Thank you!
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 ﬁnd 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

#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

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

#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?

#10 - Wrapping up…
Helping the Product Owner to build the “Right Thing”
And
Helping the Team to build “Things Right”

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

A Testers Guide To Collaborating With Product Owners

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to A Testers Guide To Collaborating With Product Owners (20)

More from TEST Huddle (20)

Recently uploaded (20)

A Testers Guide To Collaborating With Product Owners

Editor's Notes