Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
A Tester’s Guide to Collaborating
with Product Owners10 Keys to Delivering Value
Bob Galen
Copyright © 2015 RGCG, LLC
Introduction
Bob Galen
Independent Agile Coach (CSC) at RGCG, LLC
Principle Agile Evangelist at Velocity Partners
Somewhere ‘north’ of 30 years overall experience
Wide variety of technical stacks and business domains
Developer first, then Project Management / Leadership, then Testing
Senior/Executive software development leadership for 20 years
Practicing formal agility since 2000
XP, Lean, Scrum, and Kanban experience
From Cary, North Carolina
Connect w/ me via LinkedIn and Twitter @bobgalen
Bias Disclaimer:
Agile is THE BEST Methodology
for Software Development…
However, NOT a Silver Bullet!
2
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
10. Prime Directive
4
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?
5
4 Quadrants of
Product Ownership
1. Product Manager
Product Roadmap,
Collateral, Business Case /
ROI
Driving customer value
2. Project Manager
Product Backlog (WBS)
Grooming & look-ahead
Velocity-based, Release
Planning
Goal setting, Budget
3. Leader
Trade-offs, product balance
Stakeholder “management”
Member of the team;
partner with the Scrum
Master
4. Business Analyst
Story writing
Acceptance
Emergence; Spikes
Copyright © 2015 RGCG, LLC 6
Copyright © 2015 RGCG, LLC
#1, Bridge stories from
Team to the Product Owner
The key here is guiding
the translation and
execution of the user
story
Pull the Product Owner into
the sprint
Show incremental code
Shepherd sign-off
3 Amigos-based
interactions
Nail the Demo
7
Copyright © 2015 RGCG, LLC
#1, Bridge stories from
Team to the Product Owner
Coined by George
Dinwiddie
Swarming around the
User Story by:
Developer(s)
Tester(s)
Product Owner
During “Grooming, Sprint
Execution, Until…”Done”
Similar to Ken Pugh’s -
Triad
8
Copyright © 2015 RGCG, LLC
#2, Help write solid
Acceptance Tests
Consider them
as “mini-contracts” or “mini-
UAT”
3-5 minimal per story
Business constraints
Functional and non-
functional
Edge and error cases
Provide hints:
Design & Test
9
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
10
Copyright © 2015 RGCG, LLC
#3, Hold everyone “accountable”
to Definition of Done
It all starts in Grooming,
thinking of the work
cross-functionally and
with DoD in mind
Continue it in Sprint
Planning
Execute consistently; no
exceptions
Deliver to “Done”
11
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.
12
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 13
Copyright © 2015 RGCG, LLC
#4, Represent the
Customer
Don’t solve
“requirements”…solve
“customer problems”
Consider usage
KISS
Deliver value; highest
impact & priority
End-to-end solutions
14
Copyright © 2015 RGCG, LLC
#4, Represent the
Customer
The power of a Minimal
Marketable Feature
The power of the
Persona
Observe the Customer
Nordstrom Innovation
Lab:
http://www.youtube.com/
watch?v=szr0ezLyQHY
15
Copyright © 2015 RGCG, LLC
#5, Ask questions?
Be inquisitive, be curious, explore!
Ask questions
Relentlessly, Constantly,
Courageously
5 – Whys
Business value?
Lean investment
Just enough and just-in-
time
Trust your instincts, craft
Does it make sense?
16
Copyright © 2015 RGCG, LLC
#5, Ask questions?
Be inquisitive?
17
Copyright © 2015 RGCG, LLC
#6, What about the
Cost of Quality?
Meta-requirements
Security, Performance,
Maintainability
Automation investments
Agile Automation Triangle
Inspections – pairing
DoD maturity
Avoid rework?
Yes for product, no for
experiments
Quality is a TEAM
responsibility!
18
A Tapestry that Includes Threads for…
Things to do…
Features
Value
increments
Architecture
Design
Process
Quality
Testing
In a Context-Based
fashion…
Deployment
Regulatory
Dependency
Risk
Feedback
Customer
timing
Tempo
…Guiding us
towards
customer
value
Copyright © 2015 RGCG, LLC 1919
Copyright © 2015 RGCG, LLC
#7, What about the
Cost of Testing?
Risk-based
Always test what’s
available
Don’t track coverage or
time
Slack time for thinking &
creativity
Balanced across the
quadrants
20
3-Pillars of Agile Quality & Testing
Thank you!
Copyright © 2015 RGCG, LLC 21
Copyright © 2015 RGCG, LLC
#8, The Backlog is a “Plan”
help focus it towards Release!
Ask for and define a
Release Train
Encourage Release
Planning
Establish “hardening”
activities
Integration milestones –
working code
22
Copyright © 2015 RGCG, LLC
Release Train Management
Iterative model with a release target
Product centric
Focused on a production push/release
Synchronized Sprints across teams
Some teams are un-synchronized, but leads to less efficient cross-team (product) interactions
Continuous Integration is the glue
Including automated unit and feature tests; partial regression
Notion of a “Hardening Sprint”
Focused more on Integration & Regression testing
Assumption that it’s mostly automated
Environment promotion
Define a final Hardening Sprint where the product is readied for release
Documentation, Support, Compliance, UAT, Training
23
Copyright © 2015 RGCG, LLC
#9, Get to know your
Product Owner
Have lunch
Discuss the competitive
landscape, the Market
Customer challenges
MoSCoW in operation
Commitments &
Pressure
Vision & Mission; what
does “success” look like?
24
#10 - Wrapping up…
Helping the Product Owner to build the “Right Thing”
And
Helping the Team to build “Things Right”
Copyright © 2015 RGCG, LLC 25
Copyright © 2015 RGCG, LLC
Wrap-up
Contact:
https://www.linkedin.com/in/bobgalen
Get a free copy of my 3-Pillars
book by joining my RGCG
mailing list at: www.rgalen.com
Thank you!
2626