The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

9th
SEP

Scrum Product Owner

Posted by admin under Scrum Basics

There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.

In Scrum, the Product Owner is the one person ultimately responsible for the return on investment (ROI) of the product development effort. The Product Owner influences the development effort by conveying his vision to the team(s) and prioritizing the Product Backlog. The Product Owner must have the authority to make real business decisions, vision about what the product could be, and availability to the team(s). In bad implementations of Scrum, one of these elements is usually missing. For example, if I don’t have the authority to cancel product development entirely (an important ROI decision), it’s misleading to call me “Product Owner.”

This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Since Scrum is team self-organization, the Product Owner must respect the team’s ability to create its own plan of action. A Product Owner doesn’t demand additional work in the middle of the sprint. The Scrum Product Owner is discouraged from adding work to the sprint until the next Sprint Planning Meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.

It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions about what not to do.

In Large Scale Scrum, one Product Owner prioritizes a single Product Backlog for multiple teams. Multiple backlogs for one product — and multiple Product Owners — cause localized optimizations (detracting from a whole product focus), longer work-in-progress queues, thus are harmful to agility. Large Scale Scrum encourages teams to become truly cross functional and take greater responsibility for their own requirements clarifications. Cross functional doesn’t mean only dev + test, it also includes learning the requirements domain.

The responsibilities of the Product Owner are also described about halfway through this video module:
Introduction To Scrum video

Comments Feed

Reader's Comments

  1. Edward |

    @Matt,

    The “whole bunch of work that will be thrown away” would be the work that you (or your PO) just told the team to do. In extreme situations, as the article states, the PO may cancel the sprint. But if this becomes frequent, perhaps your sprint length should be shortened, or practice better judgement on what you put into the sprint.

  2. Dieter Verhofstadt |

    There are a couple of challenges for product ownership in a large organization, with multiple components being part of a big system. The scaling makes the job quite different from the usual set up of 1 team building a small system for an immediate group of stakeholders.

    Uber-POs steering a group of POs (or a program manager, or you name it) is an offhand answer. If you dig deeper, the PO now has no longer access to all stakeholders and end-users, neither the full lot, nor immediate access. This introduces a first handover that is to be avoided by all agile dictums.

    At the implementation side of the spectrum, the coordination of releases that needs to be done. In big systems the deployment chain, including functional testing across components, is usually owned by separate teams. This violates the idea of everything being embedded in the team and the PO owning the release planning.

    Last but not least, big systems require an infrastructure that cannot be mimicked at each development environment. Usually the operational infrastructure is owned by yet another team (IT) than the devlopment team, resulting in more handovers, and more importantly a difference in set up and scale between the dev and ops environments, so that not all behavior and especially performance can by duly tested.

    These issues of scaling agile are not dealt with in the theory books and often escape either the attention or the authority of a PO in big organizations. This may reduce the job of a PO to that of functional analyst, and we’re back to waterfall.

  3. MJ |

    Dieter, thank you for those observations. The best ideas we’ve seen for using Scrum with hundreds or thousands of people are described by Craig Larman and Bas Vodde at http://less.works.

  4. Dave at SME Solutions |

    Large systems require an infrastructure that cannot be mimicked at each development environment. Usually the operational infrastructure is owned by yet another team (IT) than the development team, resulting in more handovers, and more importantly a difference in set up and scale between the dev and ops environments, so that not all behavior and especially performance can by duly tested.

  5. MJ |

    Dave, I think the “cannot” in your post highlights why traditional departmentalized companies are having trouble competing with Agile ones.

Leave a Reply


CAPTCHA Image
Reload Image

Scrum Training Courses

January 16 - 18, 2017
New York, NY
Certified ScrumMaster Experience (3 days)

January 19 - 20, 2017
New York, NY
Certified Product Owner Course

April 24 - 26, 2017
New York, NY
Certified ScrumMaster Experience (3 days)

Is Scrum Training Worth the Money?