PSPO I™ Preparation Quiz – Learning Mode

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

The Product Owner is one person, not a committee, but the Product Owner may represent the desires of a committee in the Product Backlog.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

The Product Owner tracks 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. This information is made transparent to all stakeholders.

The Scrum artifacts are Product Backlog, Sprint Backlog and Increment.

The Product Backlog is an ordered list of everything that might be needed in the product and 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.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.

The Development Team is responsible for all estimates in the Product Backlog. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

The Increment is the sum of all the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints.

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Burn-down chart shows the evolution of remaining effort against time.

The Product Owner is responsible for placing the most valuable and clear items at the top of the Product Backlog.

False. Scrum does not require having aligned Sprints for multiple teams.

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

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

The Cone of Uncertainty describes the evolution of the amount of uncertainty during a project.

The Sprint is cancelled only in the case if the Sprint Goal became obsolete. If some work could not be done, the Sprint Backlog should be re-negotiated between the Product Owner and Development Team.

• DoD is used to assess when work is complete on the product Increment
• Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
• DoD ensures artifact transparency

Product Backlog refinement usually consumes no more than 10% of the capacity of the Development Team.

• The Development Team may invite other people to attend the Sprint Planning in order to provide technical or domain advice.
• The Product Owner is responsible for inviting the Key Stakeholders to the Sprint Review meeting

• Product Value Maximizer
• Lead Facilitator of Key Stakeholder Involvement
• Product Marketplace Expert

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. As new work is required, the Development Team adds it to the Sprint Backlog.

The Key Stakeholders are allowed to participate only in the Sprint Review meeting. However, any member of the Scrum Team can interact with them any time.

The Product Owner is the sole person responsible for the Product Backlog. However, he or she can delegate some work related to product backlog management to the Development Team.

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

Yes. Scrum does not prohibit the Product Owner or the Scrum Master do development work. However, it is not the best practice because it could create a conflict of interest.

Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

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.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Product Backlog refinement is the act of adding detail, 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. It usually consumes no more than 10% of the capacity of the Development Team.

In executing Value Driven Development, the Product Owner must consider the focus areas of:

• Product Value Maximizer
• Product Visionary
• Product Marketplace Expert
• Product Release Decision Maker
• Lead Facilitator of Key Stakeholder Involvement
• Other Product Owner role Considerations

According to the Evidence Based Management an Organization should focus on the following Key Value Areas (KVA) categories:

• Current Value
• Time-to-Market
• Ability to Innovate

The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs.

The PO should communicate and re-iterate his product vision early and often, reminding all involved of how to help maximize value. Utilizing the underlying empirical product planning features of Scrum, the PO should also be ready to make strategic pivots for the product vision. This vision is brought to life in a more tactical way, via the Product Backlog and iterating towards that vision every Sprint.

The PO should communicate and re-iterate his product vision to the Scrum Team and the Key Stakeholders early and often, reminding all involved of how that vision aims to maximize the value of the product and of the work the Scrum Team performs.

The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster.

The Product Owner may or may not be the one doing the legwork of gathering the marketplace data, but the PO should definitely be aware of said data/research.

The Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Refinement and in Sprint Reviews.

The PO should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

The Product Owner is the one and only person who can decide whether to release the latest increment of the product.

While Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind. Looking at it another way, the sooner you release, the sooner you can start capturing the value created by the product.

While Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind.
Another factor in the release decision is whether your customers can actually absorb your frequent releases. Most customers approach this upgrade decision using a common sense method of weighing the costs and benefits of the upgrade(new increment). This is all the more reason to make sure that your releases are of the utmost value, and offer relatively low absorption costs. Regardless of the benefits and costs, some customers will still be constrained, so this constraint should be a consideration when deciding how often or whether to release.
The PO is the one and only person who can decide whether to release the latest increment of the product.
The Increment is “Done” by its definition.

In order to maximize value, the Product Owner should identify the Key Stakeholders for the Product, and involve them as necessary throughout the development effort.

According to the Scrum Glossary, a stakeholder is “a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.”
Typically, they fall into one of three broad categories:

• The Users – The human people who actually use the product under development
• The External Customers – The people responsible for paying to use the product
• The Internal Customers – The people responsible for making the funding decisions for the product development effort

The Product Owner is responsible for making sure that the Key Stakeholders attend and interact in the Sprint Reviews, but really the Stakeholders can be involved with the Scrum Team any time where it’s valuable to have the Stakeholder input.

Inherent in the role of facilitating key stakeholder involvement is weighing and balancing the (likely) differing viewpoints of multiple stakeholders who might have varied interests in the product. The Product Owner’s responsibility is to maximize the value of the product as a whole, and this will involve an intelligent balancing of interests.

When a product grows, it is quite possible that the PO will get help from other Product Managers and others in the organization who interact regarding the customer facing activities and knowledge of the product marketplace. While it is fine for the PO to be aided by the aforementioned people, it is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties, especially the Scrum Team facing duties.

It is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties.
The Product Owner will work in concert with the Scrum Master to utilize Scrum correctly and advantageously, and try to never been seen as subverting or disrespecting the Scrum framework. When something about Scrum frustrates a Product Owner, she should consult the Scrum Master for ways to implement the Scrum framework in a way that is effective.

When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work including software and hardware development, development and releasing of products and enhancements, development and sustaining product operational environments, research and identifying of viable markets and technologies, and even more.

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.

Scrum has been used extensively, worldwide, to:

• Research and identify viable markets, technologies, and product capabilities;
• Develop products and enhancements;
• Release products and enhancements, as frequently as many times per day;
• Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
• Sustain and renew products.

The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.

The Scrum Guide recognizes the following Scrum Values: commitment, courage, focus, openness and respect.

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 Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

While the Product Owner is not the only person who may influence the ordering of the Product Backlog, the Product Owner has the “last say” on the order of the Product Backlog, and those wanting to change the order of the Product Backlog have to influence the Product Owner to do so.

User stories are a fairly common technique for representing Product Backlog Items, but other techniques can be used instead. For instance, a team can use scenarios, use cases, acceptance tests, etc. The Product Backlog might even contain a heterogeneous mix of the above.
The Product Owner should work with the rest of the Scrum Team on choosing and optimizing the techniques used to represent Product Backlog Items.

False. The Product Owner is solely responsible and accountable for the decisions in the Product Backlog. However, the legwork of managing the Product Backlog might be fully delegated to the Development Team, so it is quite possible that the Product Owner might not ever create or write a User Story or Product Backlog Item.

True. Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. The Items in the current Sprint are no longer on the Product Backlog, because they are now on the Sprint Backlog.
However, it is certainly fine for the Product Owner to add detail and clarification to the current Sprint’s work as well.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.

The Product Owner is a vital leader in terms of getting feedback from the key stakeholders in the Sprint Review.

No. The Sprint Review contains much more activities to inspect the Increment and adapt the Product Backlog.
For example:

• The Product Owner also explains what has not been “Done”;
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long-term quality of the Product.

One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.

False. The Scrum Team crafts a Sprint Goal during the Sprint Planning.

Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

The Product Backlog should make the dependency visible to all the interested parties.
Usually Items with external dependencies are not considered “Ready” for selection at the Sprint Planning.
Development Teams should deliver an Increment of product functionality every Sprint.

Non-functional requirements describe qualities of the Product being developed. For example, the Product should be secure and extensible. The only way to meet such requirements is to have them as a part of the DoD and check every Increment against these criteria.

The Sprint Review is at most a four-hour meeting for one-month Sprints.
The Sprint Retrospective is at most a three-hour meeting for one-month Sprints.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
There is no need to decompose all the Items in the Sprint Backlog. It can be done only for the first days of the Sprint.