Demystifying the Role of Product Owner

AT12 Concurrent Session 11/14/2013 3:45 PM

"Demystifying the Role of Product Owner"

Presented by:

Bob Galen RGalen Counsulting Group, LLC

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Bob Galen RGalen Consulting

Bob Galen is an agile coach at RGalen Consulting and director of agile solutions at Zenergy Technologies, a North Carolina-based firm specializing in agile testing and leading agile adoption initiatives. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing, and team leadership. He is a Certified Scrum Master Practicing, Certified Scrum Product Owner, and an active member of the Agile Alliance and Scrum Alliance. Bob published Scrum Product Ownership: Balancing Value from the Inside Out, which addresses the gap in guidance toward effective agile product management. Contact Bob at [email protected] or [email protected].

1

Demystifying the Product Owner Role

Bob Galen President & Principal Consultant

RGCG, LLC [email protected]

Copyright © 2013 RGCG, LLC 4

Introduction Bob Galen n  Somewhere ‘north’ of 30 years experience J n  Various lifecycles – Waterfall variants, RUP, Agile, Chaos… n  Various domains – SaaS, Medical, Financial Services, Computer

& Storage Systems, eCommerce, and Telecommunications n  Developer first, then Project Management / Leadership, then

Testing n  Leveraged ‘pieces’ of Scrum in late 90’s; before ‘agile’ was ‘Agile’ n  Agility @ Lucent in 2000 – 2001 using Extreme Programming n  Formally using Scrum since 2000 n  Currently an independent Agile Coach (CSC – Certified Scrum

Coach, one of 50 world-wide; 20+ in North America) q  at RGCG, LLC and Director of Agile Solutions at Zenergy Technologies

n  From Cary, North Carolina n  Connect w/ me via LinkedIn and Twitter if you wish…

Bias Disclaimer: Agile is THE BEST Methodology for Software Development…

However, NOT a Silver Bullet!

2


Outline

Introduction

n  Role of the “Product Owner” n  Product Backlogs n  Sprint Dynamics n  Goals & Criteria n  Role of the Product Owner at-Scale n  Q&A

Copyright © 2013 RGCG, LLC

The SCRUM Framework

6

3

Roles in the SCRUM Framework

How do I drive value?

Lets get the team together and figure this out!

Our burn-down is off, what’s going on?

Team Member n  Cross-functional role: QA +

Dev + Doc + Arch. + etc. n  7 +/- 2 in size n  Teams are self-organizing n  Focused teams n  Members should be full-

time n  co-located whenever

possible

Product Owner •  Contributes to Product

Backlog and Goals •  Prioritizes the backlog •  Typically a product

manager •  Accepts the teams’ work

Scrum Master •  Scrum PM like role •  Responsible for enacting

Scrum values and practices

•  Main job is to remove impediments



Inside Out?

n  Many Product Owners are conflicted… q  Training q  Overloaded q  Time allowed q  Domain & Customer familiarity

n  Serious role within Scrum and should be handled that way

n  Premise: Product Owners first responsibility is towards their Team! ü  Backlog & work orchestration ü  Interaction & feedback ü  Goal setting & acceptance ü  Leadership & partnership

4

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


Scrum Guide Product Owner Definition

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may

vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

q  Clearly expressing Product Backlog items; q  Ordering the items in the Product Backlog to best achieve goals and

missions; q  Ensuring the value of the work the Development Team performs; q  Ensuring that the Product Backlog is visible, transparent, and clear to all,

and shows what the Scrum Team will work on next; and, q  Ensuring the Development Team understands


5

Scrum Guide Product Owner Definition

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

For the Product Owner to succeed, the entire organization must respect

his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else

says.

Scrum Guide, October 2011 version, except from page 5 http://www.scrum.org/Scrum-Guides


Scrum Guide Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

q  Finding techniques for effective Product Backlog management; q  Clearly communicating vision, goals, and Product Backlog items to the

Development Team; q  Teaching the Scrum Team to create clear and concise Product Backlog

items; q  Understanding long-term product planning in an empirical environment; q  Understanding and practicing agility; and, q  Facilitating Scrum events as requested or needed.

Scrum Guide, October 2011 version, except from page 7 http://www.scrum.org/Scrum-Guides


6

Agile Atlas (Scrum Alliance) Definition

The Product Owner is the single individual who is responsible for drawing out the most valuable possible product by the desired date. This is done by

managing the flow of work into the team, selecting and refining items from the Product Backlog. The Product Owner maintains the Product Backlog and ensures that everyone knows what is on it and what the priorities are. The Product Owner may be supported by other individuals but must be a single

person.

Certainly the Product Owner is not solely responsible for everything. The whole Scrum Team is responsible for being as productive as possible, for improving their practices, for asking the right questions, for helping the Product Owner, and so on. The Development Team is responsible for determining how much

work will be taken on in a Sprint, and for producing a usable Product Increment in every Sprint.


Agile Atlas (Scrum Alliance) Definition

n  Nonetheless, the Product Owner, in Scrum, is in a unique position. The Product Owner is typically the individual closest to the "business side" of the project. The Product Owner is typically charged by the organization to "get this product out", and is typically the person who is expected to do the best possible job of satisfying all the stakeholders. The Product Owner does this by managing the Product Backlog, and by ensuring that the Product Backlog, and progress against it, is kept visible.

n  The Product Owner, by choosing what the Development Team should do next and what to defer, makes the scope versus schedule decisions to lead to the best possible product.

www.agileatlas.org - September 2013


7


Community Disagreement over the Role

n  Single individual or collaborative group? q  Scrum Yahoo Group there was discussion in the Fall of 2008 regarding

whether it could be done by a small group. Schwaber stated that “there can be only 1”.

n  Oh, and are they a part of the team?

q  Scrum team vs. Development team q  For example, do they attend the Sprint Retrospectives? q  Can they perform work within the Sprint?

The Product Owner Is…

n  The primary “keeper” of the teams’ Product Backlog

q  Required to provide a balanced and nuanced Product Backlog

q  A writer of requirements that are well defined, granular, and most importantly testable

n  Is responsible for considering

the capability of their team (skills, strengths, weaknesses, #’s, etc.) and setting the Backlog to amplify successful execution

n  Provides the Product Vision – where the team “going”; shares the voice of the customer (VOC)

n  Needed to be available daily for work feedback, acceptance, and scope adjustment discussions

n  Communicates externally to Stakeholders and buffers the team from potential distractions

n  Accountable for the teams results meeting business expectations


8

The Product Owner Is not…

n  The manager of the team; nor responsible for performance management. They can give performance feedback, but only when requested to do so. This is the Functional Managers responsibility

n  A decider of technical direction (architecture, design, etc.), that is the Teams responsibility

n  A contributor to Story or Task estimates; that is the Teams responsibility

n  Responsible for the overall skill of the team; selecting team members; or fighting for individuals. The Functional Managers tries to effectively balance the teams


Product Owner role according to Roman Pichler

n  Product Vision n  Product Business Model (value & benefit) n  Product Roadmap Planning n  Collaborate with the Scrum Master and Development team n  Describe UX and Features n  Determine Goals (Sprint) n  Research / Validation for Feedback (effective Reviews, etc.) n  Review Feedback & Adjust – Feature(s) and Roadmap n  Look after the Budget n  Coordinate Launch

http://www.romanpichler.com/blog/roles/the-product-owner-responsibilities/

Copyright © 2013 RGCG. LLC 18

9

Ownership/Role Balance

n  Product Owner owns: What n  Team Owns: How and How Long n  Scrum Master owns: Agile Principles &

Practices

Challenge & discuss – Yes; but in the end, TRUST the ROLES!



Product Backlogs

10


Product Backlog Simple list, or something else?

n  All work vs. feature work? One list vs. many? q  Features, Technical, Quality, Release, etc. q  Excel Product Backlog Items (PBIs) vs. User Stories vs.

something else altogether? Connecting to other artifacts?

n  How do you orchestrate or influence – Emergent Practices? q  Not writing Too Much…Too Soon q  Architecture, feature sets, usability, design, etc. q  Balancing look-ahead?


Where do User Stories “Come From”?

n  Stories come from: q  Customer wants/needs; bugs, maintenance, technical debt q  Product Owner capturing individual stories; team members q  User Story Writing Workshops

n  Who writes them? q  Initially – the Product Owner or individual team members q  Eventually – everyone “touches” them via Backlog Grooming q  It Takes a Village!

11


Product Backlog as… WBS?

n  Partitioning the Backlog - workflow q  Opening Moves – emergent understanding, beginning well q  Middle Game – stabilization, value, mass q  End Game – integration, quality, customer delivery

n  Design or look-ahead activity n  Features n  Dependencies & X-team hand-offs n  Iterations & Milestones n  Transparency & “progress tracking”

Iceberg Model


12


Backlog ‘Tension’ Points

n  How many items? Size – does it matter? Are they all the same?

n  Prioritization & Valuation methods?

n  FutureCast – painting a compelling picture of the “Tactical Now” vs. the “Strategic Later” w/o scaring everyone to death…

Granularity heuristic Use the 20/30/50 rule. 20% proper stories ready to roll. 30% are epics -

bigger stories that will eventually be split out into smaller fine grained ones (only as needed). The last 50% are themes - vague

ideas about long term product direction and I never put much effort here because it’s almost always wrong.


Grooming your Backlogs Approaches?

n  The Product Backlog is Organic and needs care & feeding q  Reserve time for collaborative, team-based

grooming meetings OR ‘Assign’ individual stories to team members

q  Combination of these two

n  Keeping it interesting, grooming at 3 levels: q  20%: what’s right around the corner – are we ready? q  30%: what’s 3-4 sprints away – are we getting

clearer? q  50%: what’s the future looking like? Break those

things down…

26

13


Grooming your Backlogs Look-ahead

n  Judicious use of Research Spikes to gain understanding; output of a Spike: q  Knowledge, solid stories, prototype code, design(s), tooling, etc.

n  In some cases, run Iteration #0 types of exploratory iterations to get broad information under your feet

n  Always looking for new ‘contributions’ q  Technical, quality, release workflow, etc. q  Rarely do they seem to be forthcoming; encourage them from the

team

27


n  Bring goals & stories to the table; but be open to change n  Listen actively n  Don’t predetermine size nor complexity; trust your team n  Don’t negotiate…collaborate n  Organic explorations of scope and options as you get

closer to execution n  Explore execution dynamics – architecture & design,

testing, non-functional, deployment, and risk n  Apply pressure on – value flow, quality & sustainable

pace

Active Backlog Grooming

14

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



User Stories Hierarchical Types

n  Epic – a huge idea, spanning multiple teams and multiple sprints. Could be several releases. Rarely well understood.

n  Theme – a large idea; spanning multiple teams, but normally fitting into a release. Normally a simple marketing container – for planning & prioritization.

n  Feature – a large idea; spanning multiple teams, always fitting into a release. Assigned team owner.

n  User Stories – work items for a given sprint. Well understood. All work delivered in story-units.

30

15


User Stories Hierarchical Types

Hierarchy Attributes Visited

Epic •  Defer planning precision - Visioning •  Container, X-teams •  Roadmap & Portfolio Level Planning

•  Annually, phased planning, roadmap forecasts

Theme or Feature

•  Container, potentially X-teams •  Release Level Planning (1-2

releases ahead) •  High Level Research – Feature

Spike

•  Quarterly to monthly

•  Track feature delivery

Story

•  Team work item •  Can be quite large (13 – 20 points) •  Sprint Planning •  Low Level Spikes

•  Monthly to Sprintly

•  Track story delivery

31

Product Backlog Wall

Source: http://mhjongerius.tumblr.com/post/16222404998/our-new-product-backlog-wall


16


Sprinting


Sprint Dynamics Planning

n  Always be ready; strategize with your Scrum Master

q  No surprises for the team! q  You’re part of the team, stay engaged in the entire process q  Drive everything with ‘goals’

Point of Sprint Planning 1.  To share and gain the teams’ commitment toward the Sprint Goal 2.  To identify the set of User Stories that align with and are feasible

to deliver within the Sprint 3.  To identify the Tasks associated with delivering those User

Stories In that priority order and leading to goal-driven work

17


Remember -- The Triad

Collaboration

Customer

Developer Tester

Ken Pugh has written a book on ATDD and uses the “Triad” to amplify this collaborative pairing between roles…Product Owner is central to that!

Collaboration FIRST…

Automation

SECOND…


Sprint Dynamics Execution

n  Stay engaged q  Attend daily Scrum q  Observe the trending; consider adjustments as the sprint evolves q  Actively participate…perhaps in testing; certainly in grooming

n  Looking-ahead q  Grooming the Backlog in ALL dimensions q  Collaborating with Customers & Stakeholders

n  Observe & understand your team dynamics q  Strengths, capabilities, weaknesses, etc.

18


Sprint Dynamics Execution

The very next day, the Product Owner gave me a call. Again, 5 a.m. on the west coast, but hey… he had a Sprint progress observation and wanted my advice. He said it seemed clear that the team was going

to miss delivering some of the features for the Sprint.

However, he was OK with that and wanted to know if he could start removing or reframing Stories in order to increase the teams ability

to meet the Sprint Goal?

So, here’s a Product Owner who, in their very first Sprint, gets the difference between planned scope versus actual team capacity and

the need for ongoing adjustments. Ah Ha—I thought!


Sprint Review A Defining Moment

n  Take ownership of attendance q  Ensure key stakeholders are going to attend; If not, ask them to send someone q  Make it compelling to them; sell the opportunity q  Same ‘ceremony’ every Sprint?

n  Help the team prepare q  Have a ‘script’; don’t over-prepare, but DO NOT wing it q  Product Owners should “Set the Stage” for the Sprint q  It’s not simply about features

n  Other artifacts, test automation, prototypes, etc. q  Whole team approach

19


Sprint Review A Defining Moment

n  Serve as the M/C of the review q  Ensure clarity of communication q  Pace & transitions

n  Call it! At a Story level and at a Sprint level… q  Pass or Fail?

n  Connect the dots q  Relative to challenges in the sprint q  Relative to release goals q  Relative to customer expectations

Copyright © 2013 RGCG, LLC 40 40

Review Flow

§  Organized & Thoughtful Flow q  Introduction q  Team Chart q  Acknowledgements - Appreciations q  Sprint Goal q  Strategy? Success? Efforts? Discoveries? Results? q  Demo’s; Q&A q  Coming Attractions q  Fist-of-Five Towards Improvement q  Close

20


Sprint Retrospective

n  And as a member of the team… Attend the retrospective

q  Actively participate q  Bring in an outside “business perspective” q  It’s ok to share your pressures q  Quality impressions; Continuous Improvement impressions q  Focus on Predictability, Quality, and Value


Goals

21

43

ü Release Goals ü  Sprint Goals ü  Feature Acceptance

n  Over Features, Stories, and Tasks

n  Value-driven n  Envisioning n  Chartering

Leading with Goal Setting



Establishing Goals & Criteria Why it’s Crucial?

n  Agile teams are essentially self-directed, so plans don’t drive behavior or success…

n  People do and Goals drive the Team!

n  The team then swarm around the goal(s), using their creativity and teamwork to figure out: q  What’s most important q  How to achieve it q  Always looking for simple & creative—20% solutions

22


Notions of Done-ness

n  Need to define “Done” from team members perspectives n  If you’re a developer, what does “I’m done with that story” mean?

ü  Code complete ü  Code reviewed (paired) ü  Checked in – build successful ü  Unit tests developed – passed ü  Integration ü  QA collaboration ü  Run by the Product Owner

n  Every type of task should have a definition of done-ness! How else could you estimate the work?


Story Acceptance

n  Each User Story should have acceptance criteria as part of the card

n  They should focus on the verifiable behavior, business logic, for the story

n  Typically, they are crafted by the Product Owner q  Leveraging skills of Business Analysts and Testers

n  Story acceptance tests are normally automated and run as part of feature acceptance AND regression

23


User Story Examples

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

47


Iteration / Goal Acceptance

n  Each Scrum Sprint has a Product Owner determined Sprint Goal

n  Usually sprint success is not determined by the exact number of completed stories or tasks

n  Instead, what most important is meeting the spirit of the goal

Deliver a 6 minute demonstration of the software that demonstrates our most compelling value features and achieves

venture capital investment interest

24


Release Criteria

n  Goals and objectives for the entire project release n  Usually they are multi-faceted, defining a broad set of

conditions q  Required artifacts q  Testing activities or coverage levels q  Quality or allowed defect levels q  Results or performance metrics achievement levels q  Collaboration with other groups q  Compliance levels

n  That IF MET would mean the release could occur.


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.

Contributed to Chapter 20 of Lisa Crispin & Janet Gregory’s new 2009 Agile Testing book

25

51 Copyright © 2013 RGCG, LLC 51

n  Of Course, Quality isn’t a simple pattern, it’s a façade

n  Jim Coplien responding to a point on Scrum Alliance leadership list (paraphrased)…

Value doesn’t matter when examining technical debt. Rather, that cleaning up after yourself transcended the normal determination of business value and

was simply an inherent part of delivering software. That it is our responsibility and is non-negotiable. The decision-making wasn’t FOR the

business-side, but instead resides within the team.

n  Listen to your team! n  Ask the ‘Right’ questions!

Who Decides on Quality?


Role of the Product Owner At Scale

26

Chartering

Chartering Components q  Project visioning q  Shared stakeholder

expectations q  Goals & Success criteria q  Approaches, Process,

Methods q  Team, Communication,

Metrics q  Scope & Budget q  Risk handling q  Sign-off

Agile Practices

q  Road-mapping q  Backlog grooming, Story

writing q  Collaborative release

planning q  Crystal – Blitz Planning q  Patton – Story-Mapping q  XP – Planning Game


Product Management

n  Facilitating high level visioning q  Competitive landscape q  Technology and corporate direction

n  Chartering of new projects n  Product Road-maps & release orchestration n  Story development

q  Epic -> Feature (MMF) -> Story stream q  Priority & value q  Technical clarity (quality, architecture, technical debt)


27

Portfolio Management

n  Something similar to the Lean Dog – Big Visible Room for executives to q  http://www.slideshare.net/LeanDog/agile-from-the-top-down

n  Instead of an electronic dashboard, q  Vision, Portfolio, Assignments, Value, ROI q  Release plans, application funnel q  Capability and competency q  Agile practices / team alignment


Scrum of Scrums

n  Periodic meeting – similar to daily stand-up

n  Focus: q  X-team interactions,

dependencies, and blocks q  Release planning &

communication q  Frequency dictated by state q  Information radiators: release

burndown, impediments, etc.

n  Key reference

q  http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting


28

Scrum of Scrums board Story + Status (across teams)

Source: http://www.xqa.com.ar/visualmanagement/2009/08/scrum-of-scrums-making-it-visual/


In Closing…

n  Product Ownership (by the Customer, Stakeholder, BA, Product Manager) is the most crucial role within agile teams, providing—

ü  Inspirational vision ü  Clear goal – setting; quality balanced ü  Prioritized requirements – value based, workflow ü  Measured & accepted results ü  Scaled appropriately ü  Focus towards the team first


29


Wrap-up

•  What were the most compelling ideas, stories, or lessons? •  What adjustments will you make in your Product

Ownership? •  What ideas did I miss?

•  Final questions or discussion?

Thank you!

68 68

Contact Info

Bob Galen

Principal Consultant, RGalen Consulting Group, L.L.C.

Experience-driven agile focused training,

coaching & consulting

Contact: (919) 272-0719 [email protected] www.rgalen.com

Blogs

Project Times - http://www.projecttimes.com/robert-galen/ BA Times - http://www.batimes.com/robert-galen/ Podcast on all things ‘agile’ - http://www.meta-cast.com/

69 Copyright © 2013 RGCG, LLC 69

Demystifying the Role of Product Owner

Technology

Transcript of Demystifying the Role of Product Owner