Tips to Get the Product Owner Certification from Scrum.org
After I got the Scrum Master certification, I realized how much I had learned while I was studying, so I also decided to get the Scrum.org Product Owner certification. Below I share my process, what I studied, and what helped me to pass the exam.
You will also find information about the Product Owner role, along with a Scrum framework recap, and some useful links to study. I hope you enjoy it and learn something new. This post was created based on the Scrum Guide document.
Product Owner Recap
Product Owner Role
For the Product Owner to succeed, the entire organization must respect their decisions. The Product Owner is responsible for maximizing the value of the product. How this is done will vary widely.
Scope
During the Sprint, the scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Requirements
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.
Sprint Planning
Sprint Planning serves to plan the work to be performed in the Sprint. What can be achieved may be influenced, however, by additional practices that are not prescribed by Scrum.
Estimation
The Development Team is responsible for all estimates since the people who will perform the work make the final estimate.
Product Backlog
The Product Owner manages the Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market. Keep in mind that the value is likely to vary across products and organizations.
The primary tool for the Product Owner to uphold transparency is the Product Backlog. Product Backlog is a living artifact that is actively maintained and updated to reflect reality. Scope may be re-negotiated if the effort grows much higher than anticipated.
Stakeholders
The Product Owner represents the stakeholders to the Scrum Team, which includes representing their desired requirements in the Product Backlog. A Product Owner engages actively and regularly with stakeholders. However, to minimize the disturbance to the development progress and keep focus high, the stakeholders have a formal role in the process at the Sprint Review only.
Sprint Backlog
The Sprint Backlog rather than the Product Backlog includes at least one high-priority process improvement identified in the previous Sprint Retrospective meeting.
Scrum Recap
Purpose of the Scrum Guide
Scrum is a framework for developing, delivering, and sustaining complex products.
Definition of Scrum
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Transparency
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
Inspection
Scrum users must frequently inspect scrum artifacts and progress toward a Sprint goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum Values
When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
The Scrum Team
The Scrum Team consists of a Product Owner, Development Team, and Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others outside of the team.
The Product Owner
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog. The Product Owner is one person, not a committee, although they might represent the desires of a committee in the Product Backlog.
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of the “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
The ideal size for the team is three to nine people. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
The Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Scrum Events
Prescribed events are in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something.
The Sprint
The heart of the Scrum is a Sprint, a time-box of one month or less during which a “Done,” usable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint Planning
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that participants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
Sprint Goal
The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.
Sprint Backlog
The Product Backlog items selected for the Sprint plus the plan for delivering them is called Sprint Backlog. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team that is held every day of the Sprint. The Daily Scrum is held at the same time and place each day to reduce complexity and is an internal meeting for the Development Team.
If others are present, the Scrum Master ensures that they do not disrupt the meeting. Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge.
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
This is at most a four-hour meeting for one-month Sprints. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This is at most a three-hour meeting for one-month Sprints.
Scrum Artifacts
Scrum’s Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specially designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog is dynamic; it constantly changes to identify what the product needs in order to be appropriate, competitive, and useful. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove the product’s completeness when “Done”. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.
Refinement
Product Backlog refinement is the act of adding details, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. Refinement usually consumes no more than 10% of the capacity of the Development Team.
Monitoring Progress Towards Goals
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal.
Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done.” If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Transparency
The Scrum Master must work with the Product Owner, Development Team, and other parties involved to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. Transparency doesn’t occur overnight, but is a path.
Definition of “Done”
When a Product Backlog item or an Increment is described as “Done,” everyone must understand what “Done” means. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.
The purpose of each Sprint is to deliver an Increment of potentially releasable functionality that adheres to the Scrum Team’s current definition of “Done.” Each Increment to all prior Increments and thoroughly tested, ensuring that all Increments work together.
Canceling a Sprint
A Sprint can be canceled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although they may do so under influence from the stakeholders, the Development Team, or the Scrum Master. A Sprint would be canceled if the Sprint Goal becomes obsolete.
When a Sprint is canceled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially released, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Keep me posted about your process, and as usual, if you have any questions or comments, feel free to share them with me!
Important Links
Product Owner Scrum Certification
Professional Scrum Certified Count
Product Owner Learning Path
The Scrum Guide
Product Owner Open Assessment
Materials to Study
The Empirical Product Owner
The Three Pillars of Empiricism (Scrum)
Empiricism, the act of making decisions based on what is
Agile Manifesto
Agile is constant change
Empiricism is an Essential Element of Scrum
Escaping the Predictability Trap
Professional Scrum Competency: Understanding and Applying the Scrum Framework
A Leader’s Framework for Decision Making
Professional Scrum Competency: Developing People and Teams
Professional Scrum Competency: Managing Products with Agility
Additional Resources
Other Certifications
👋 Feel Free to Clap and Share your Thoughts!
Find more at our LinkedIn, Instagram, and Twitter. Check our podcast. Follow our LinkedIn page and Newsletter!
Disclosure: At PM101, we strive to provide our readers with valuable and honest information on Product and Program Management. As a way to support the blog and continue providing valuable content, some blog posts may contain affiliate links or promotional content. By clicking on these links and making a purchase, the writer may receive a small commission at no additional cost to you. This commission helps to keep the blog running and allows the writer to continue providing valuable content and increasing her coffee and kombucha consumption. Rest assured, we will always provide honest and informative content and use affiliate links and promotional content only as a means to generate revenue to support the blog.
