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.
Attend every Daily Scrum to answer functional Questions on the discussed Sprint Backlog items.
Update the work plan for the Development Team on a daily basis.
Work with the Development Team on Product Backlog refinement.
Create financial reporting upon the spent hours reported by the Development Team.
Collaborate with stakeholders, user communities and product managers.
They should work apart as much as possible in order to keep the concerns of business and technology separated.
They collaborate often so the Product Owner can make informed decisions in balancing effort and value of Product Backlog items.
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 Development Team builds Increments keeping end-user and stakeholder concerns in mind.
They should share no more than the Sprint Planning and the Sprint Review meeting.
Cancel the Sprint.
Change the Sprint Goal.
Re-work the selected Product Backlog items with the Development Team to meet the Sprint Goal.
Skip Product Backlog refinement activities.
Inform management that more resources are needed.
At the Sprint Review the Product Owner shares the current state of Product Backlog, which, combined with the inspection of the Increment, leads to an updated Product Backlog.
At the Daily Scrum the Product Owner inspects the Sprint burn-down for progress towards a complete Increment and re-planning the team’s work.
At the end of Sprint Planning the Product Owner verifies the Sprint Backlog for completeness in order to allow the Sprint to start.
The Product Owner invites stakeholders to the Sprint Review to learn how the current state of the marketplace influences what is the most valuable thing to do next.
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
Effort first, then value
Development cohesion as indicated by the Development Team
Lowest development cost in order to maximize ROI
The availability of resources and skills for implementation
Whatever is most appropriate for the Product Owner to achieve the product’s goals and to optimize the value received
Describing an Increment at the Sprint Planning and make sure that the Development Team delivers it by the end of the Sprint
Creating and sustaining a Product Backlog that maximizes value and represents the needs of the stakeholders
Refining the top level Product Backlog items until they are ready to be handed over to the Development Team
Writing the User Stories so they are understandable to stakeholders
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
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.
The Product Owner writes the User Stories as provided by the stakeholders.
The Product Owner has the final call over the requirements and should involve the stakeholders as little as possible.
The Product Owner actively asks for stakeholder input and expectations to process into the Product Backlog.
The Product Owner provides the stakeholders with acceptance forms at the Sprint Review to record their formal agreement over the delivered software.
Technical debt causes a greater percentage of the product's budget to be spent on maintenance of the product. Incorrect answer
Technical debt is not a Product Owner concern, because technical debt is only an issue for the Development Team.
Technical debt does not influence the delivery of value.
The velocity at which new functionality can be created is reduced when you have technical debt.
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