• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scrum - Product Owner

Scrum - Product Owner



Scrum - Product Owner

Scrum - Product Owner



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Scrum - Product Owner Scrum - Product Owner Presentation Transcript

    • Promovendo Diálogosplanb.com.br
    • Product Owner The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.
    • Product Owner The Product Owner is the sole person responsible for managing the Product Backlog. 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.
    • Product Owner The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
    • Product Owner 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.
    • Product Owner 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.
    • The Vision The vision should communicate the essence of the future product in a concise manner and describe a shared goal that provides direction but is broad enough to facilitate creativity. - Roman Pichler
    • The Vision A shared vision isn’t an idea. It’s a force in people’s hearts. An effective product vision should describe your target customer or user and the value proposition for that customer/user. It should be short and memorable and pass the “elevator test”.
    • Scrum Communication
    • Product Backlog User Story format is usually expressed as: “As a user role (WHO) I want some functionality (WHAT) So that get some business value (WHY)”
    • Product Backlog • Story estimated at 13 story points or less • Story written in user story format • Story has at least the happy path test case written • Story has a business value estimate • Story has an initial UI sketch mockup • Constraints on story indicated
    • Business Value • actual money customers are willing to pay for the product • reduction in costs of development or implementation of the product • legislative penalty associated with non-delivery of functionality • reduction in risk or gain in knowledge about a risk • time to market or first mover advantage • reputation
    • Scrum Masters Scrum Master Service to the Product Owner The Scrum Master serves the Product Owner in several ways, including: - 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.
    • Working with the team
    • Working with the team A good metric to aim for as Product Owner is that 85% of the team’s queries should be answered in 15 minutes or less.
    • Incremental
    • Incremental Like the illustration above, we want to start by describing the bare working features (of the whole application) and then slowly add more detail as we go. This is quite different from working in phases. The principle difference is that we want to get to a “walking skeleton” which demonstrates a full set of functionality while limiting the depth of the individual features. This allows us to get a feel of the whole system end-to-end as quickly as possible. Phases on the other hand try to select components or modules to defer.
    • Incremental
    • Release Planning
    • Definition of Done
    • The Sprint Goal A good sprint goal provides the same guiding effect that we observe from a good product vision. It provides context for the team, allowing them to make good decisions when executing on their commitment.
    • The Sprint Review The vital contribution of the Sprint Review is in the collaboration between the team, the Product Owner and the stakeholders present. To ensure that this happens it is important that the Product Owner manages the stakeholder expectations in preparation for the Sprint Review.
    • Retrospective
    • Fontes http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf http://www.scrumsense.com/