Scrum Professional Product Owner Training

Cancel the Sprint

Change the Sprint Goal

Skip Product Backlog refinement activities.

Inform management that more resources are needed.

Re-work the selected Product Backlog items with the Development Team to meet the Sprint Goal.

Validating assumptions of value through frequent releases

The order of the Product Backlog

Devising a formula for a neutral calculation of value

Setting value on individual Product Backlog items using Value Poker

They should share no more than the Sprint Planning and the Sprint Review meeting

They collaborate often so the Development Team builds Increments keeping end-user and stakeholder concerns in mind.

The Product Owner should be with the Development Team full-time to grow a deep understanding of the technology being used.

They collaborate often so the Product Owner can make informed decisions in balancing effort and value of Product Backlog items.

They should work apart as much as possible in order to keep the concerns of business and technology separated.

Using value points is the ultimate way for a Product Owner to predict the value that the product will provide.

It is a good practice, keeping in mind that market reception is the best measure of value.

Calculating value points is an upfront approach that conflicts with the empiricism of Scrum, and is therefore not acceptable

A business analyst represents the Product Owner to make decisions on his behalf during the Sprint. This way the Product Owner can accept the work at the Sprint Review without further involvement.

By making sure a Sprint does not stop until all testing is done, and the work is verified by the Product Owner.

Through frequent delivery of Increments of the product into the market

At the end of each Sprint, a detailed report with all test cases and test results is available.

Through the assurance that a Development Team finishes all work on the Sprint Backlog.

Effort first, then value

Whatever is most appropriate for the Product Owner to achieve the product's goals and to optimize the value received

The availability of resources and skills for implementation

Lowest development cost in order to maximize ROI

Development cohesion as indicated by the Development Team

Within the Sprint, the Development Team makes the best decisions possible to assure progress toward the Sprint Goal, re-aligning with the Product Owner once he/she is available again.

In a permanent state of unavailability, a new Product Owner needs to be appointed. Development efforts without a Product Owner are not employing Scrum

There should be a Product Owner team to allow a different person from that team to instantly take over the role of Product Owner.

Development of functional requirements stops until the Product Owner is available again

The money spent on development of the product, often a fixed cost per Sprint multiplied by the Sprints required

All investments required to conceive, develop, operate and maintain the product

The accumulated cost over the earned value of the product

The Development Team. As a collective, they have a complete view of the work needed to transform Product Backlog items into Increments of product.

The PMO. They have all the history on projects delivered, and this enables the IT department to make delivery commitments.

The Product Owner. The Product Owner is required to commit on delivery to the users and the stakeholders

By measuring that velocity has increased since the last release.

By releasing often, and updating key performance indicators (KPIs) on value after every release and feeding this information back into work on the Product Backlog.

By measuring the actual time spent on development versus the time estimated for development.

By the Product Owner and stakeholders accepting the Increment at the Sprint Review

It is a living artifact of product requirements that exists and evolves as long as a product exists.

It is a formally approved list of requirements to be implemented over a set period.

It is a detailed list of functionality from which the Development Team draws items, to be complemented by a separate Technology Backlog managed by the Development Team.

It is a list of references to Use Case documents that are stored in a central repository. The references should be viewable and clickable by anybody to enhance transparency.

The development organization (or Development Team if none is available from the development organization)

The Scrum Team, in a collaborative effort where the result is the common denominator of all members' definitions

The Product Owner as he/she is responsible for the product's success

The Scrum Master as he/she is responsible for the Development Team's productivity