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

[email protected]

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!


Testing Experience – 28/2014 35

pyramid, continuous integration, XP technical practices, and sup-port for ALM-distributed collaboration tools.

Often it is the place towards which organizations gravitate first – probably because of our generic affinity for tools solving all of our challenges. An important way to think about this pillar is that it is foundational, in that the other two pillars are built on top of the tooling. And organizations often underestimate the importance, initial cost, and ongoing costs of maintaining foundational agility in this pillar. Continuous investment is an ongoing challenge here.

Finally, this pillar is not centric to the testing function or group. While it includes testing, tooling, and automation, it inherently includes ALL tooling related to product development across the entire agile organization. It provides much of the “glue” in cross-connecting tools and automation towards efficiency and quality.

2. Software Testing: This pillar is focused on the profession of testing. On solid testing practices, not simply agile testing practices, but leveraging the teams’ past testing experience, skills, techniques, and tools. This is the place where agile teams move from a trivial view of agile software testing (which only looks at TDD, ATDD, and developer-based testing) towards a more holistic view of quality.

It is a pillar where the breadth and depth of functional and non-functional testing is embraced. Where exploratory testing is un-derstood and practiced as a viable testing technique. It is where the breadth of non-functional testing is understood and applied to meet business and domain needs, including performance, load, security, and customer usability testing.

By definition, this is where testing strategy resides, where planning and governance sit, and where broad reporting is performed. I am NOT talking about traditional testing with all of its process focus

and typical lack of value. But I AM talking about effective profes-sional testing, broadly and deeply applied within agile contexts.

3. Cross-Functional Team Practices: Finally, this pillar is focused on cross-team collaboration, team-based standards, quality attitudes, and, importantly, on building things properly. Consider this the soft-skills area of the three pillars, where we provide direction for how each team will operate – consider them the “rules of engagement”.

For example, this is the place where good old-fashioned reviews and inspections are valued. This would include pairing (across ALL team members), but also slightly more formal reviews of architecture, de-sign, code, and test cases. It is a place where inspection is performed rigorously, as established in the teams’ Definition-of-Done. Where refactoring of the code base and keeping it “well kept” is also of primary importance.

Speaking of Definition-of-Done, this is the pillar where cross-team physical constraints, conventions, and agreements are established. But, more importantly than creating them, it is where the team makes commitments to consistency and actually “holding to” their agreements. Another important focus is on group integrity in con-ducting powerful retrospectives and fostering continuous improve-ment in the long term.

Foundational PracticesBut beneath the Three Pillars are some foundational principles and practices that glue everything together. For example, taking a whole-team view of quality and testing, where it is not just the job of the “testers”, but of everyone on the team. I still find far too many agile teams that relegate the ownership of quality and testing only to testers.

Pyramid-based Strategy: (Unit + Cucumber +

Selenium)Continuous Integration

Attack technical infrastructure in the

BacklogVisual Feedback –

DashboardsActively practice ATDD

and BDD

Whole Team Ownership of “Quality”Knowing the Right Thing to Build; And Building it Right

Healthy – Agile Centric MetricsSteering via: Center of Excellence or Community of Practice

Strategic balance across 3 Pillars; Assessment, Recalibration, and Continuous Improvement

Risk-based testing:Functional &

Non-FunctionalTest planning @ Release

& Sprint levelsExploratory Testing

Standards – checklists, templates, repositoriesBalance across manual,

exploratory & automation

Team-based PairingStop-the-Line Mindset

Code Reviews & Standards

Active Done-NessAggressive Refactoring

of Technical DebtUser Stories, “3 Amigo”

based Conversations

Software Testing Cross-FunctionalTeam 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

Technology

years n

sprint q

velocity partners n

kanban experience n

mini uat n

north carolina n

user story q

error cases n