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
Have you ever wondered what makes a good Product Owner? It’s a broad and deep role that is often filled with a hodgepodge of differently skilled individuals. Many organizations struggle to understand its importance as they scale their agile transformations. What about exceptional Product Ownership? What does that entail? In this highly collaborative session, Bob Galen explores the Four Quadrants of Effective Product Ownership—Product Management, Project Management, Leadership, and Business Analysis. Each of these critical aspects of the Product Owner role supports the agile team. Together, they lead to well-constructed product backlogs with an emphasis on creating high quality and high value products. Leave this session with a better understanding of the breadth and depth associated with outstanding Product Owners, a newfound respect for how challenging the role is, and with immediate insights and actions for improving your organization’s Product Ownership.
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
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].
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…
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
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
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
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.
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.
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
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
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?
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!
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”
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
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.
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
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.
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!
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
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
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
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?
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
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
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
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
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/