The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

9th
SEP

Scrum Product Owner

Posted by admin under Scrum Basics

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. I’ll begin by discussing the Product Owner because it is the most demanding of the roles.

In Scrum, the Product Owner is the one person responsible for a project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the scrum backlog, and prioritizing it based on business value. Of course, he or she must also consider the stakeholders (to make sure their interests are included in the release) and the team (to make sure the release is developed by the deadline and within budget). As such, the Product Owner must be available to the team to answer questions and deliver direction.

But this combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan of action. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint. Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner is discouraged from altering 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.

Furthermore, it is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions—that the team might not appreciate—during sprint planning. However, the Product Owner is the one person who must face the music if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important, when they are developed, etc. Just as the development team must produce the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.

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

posted by: scrum methodology

Be Sociable, Share!
Comments Feed

Reader's Comments

  1. ZenAgile Roles: Agile Sensei « Zen Agile |

    [...] I read about the roles in other agile approaches — Scrum Masters, Product Owners, Chief Architects, and Domain Experts — the essence of mentoring and passing on the way of [...]

  2. Agile and Scrum « Architecture and Design |

    [...] has three fundamental roles: Product Owner, ScrumMaster, and team [...]

  3. Produktägare i användarcentrerade agila projekt « Helt sonika |

    [...] ett traditionellt Scrum-team är produktägaren den som prioriterar vad som ska utvecklas, den som har en vision om en produkt och den som ska [...]

  4. Doc List |

    “In Scrum, the Product Owner is the one person responsible for a project’s success.”

    Seriously? I think this is seriously overstated. There is no one person responsible for a project’s success, regardless of whether you are doing waterfall or agile, scrum or XP.

    There’s no question that there must be a Product Owner. But “the one person”? No.

  5. Edwin Dando |

    There is a free Product Owner position description here http://www.clarus.co.nz/downloads/product-owner-job-description.html if it is of interest to anyone.

  6. it is not the destination that matters, but the journey you take. « kellrodney |

    [...] most successful technique we implemented to get our Product Owners (PO) to increase their involvement with our Agile process was to encourage a ticket writing [...]

  7. Scrum – An Agile Process « arunkumarhn |

    [...] has three fundamental roles: Product Owner, ScrumMaster, and team [...]

  8. Why I really love SCRUM | Daniel R. Odio - Hardcore LifeHacker Entrepreneur in Silicon Valley |

    [...] on the department) can last several hours and encompasses the entire team.  It’s where the project (or product) owner moves ideas out of the icebox and into the backlog based on the project’s requirements. [...]

  9. The ScrumMaster Role « collinscrummaster |

    [...] are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team. The second role I’d like to examine is the ScrumMaster, who, [...]

  10. Matt Pearcey |

    “Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner cannot alter the sprint until the next sprint planning meeting.”

    Really? So as a business owner expecting to see a benefit from adopting scrum, you’re telling me that I need to invest in a whole bunch of work that will be thrown away simply to maintain the purity of the process?? Come on! I’ll wager that if it is your dollars being wasted on your team doing pointless work, you’d soon adopt a more pragmatic view.

    It’s a good approach, and works well in my experience, but it’s throwaway comments like this that immediately put the barriers up.

  11. CASE/Teamarbete – delkurs 6, 17-18 december 2012 « PHP-utvecklare |

    [...] jobbar på varsin modern webbyrå och fick vart och ett tillfälle att träffa den tänkta kunden/produktägaren för Trader-projektet. Detta var webbyråns första kontakt med den potentiella kunden, Olle Nider, [...]

  12. ewok_bbq |

    some Swedish stuff – I think. :-)

  13. Stella |

    Can there be more than 1 product owner? If the product is complicated and the requirements challenging, can’t there be a team of product owners?

  14. ewok_bbq |

    Thanks Stella for the question. we can set up things in a number of ways. One way is to have 1 Product Owner (PO) per 1 Scrum Team working against 1 or more product backlogs. If you have multiple teams working against 1 or more backlogs then yes you will end up with multiple POs working together. This means that that there will indeed be a heirarchy to that group with a “uber-PO” at the top. Bas Vodde and Craig Larman write about it at great detail in their book here. The other way to do this is to have 1 PO across multiple teams but I haven’t seen that work in practice very well so I wouldn’t really recommend it.

  15. 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.

  16. ewok_bbq |

    Thanks Edward for the response.

  17. Value Driven Development | SEP Blog |

    [...] etc. building a product.  Everyone had their own view of what needed to happen.  As one of many product owners on the project, I had to balance the needs of the customer, the requests of management, and the [...]

  18. Scott Logic » Isolated Scrum: Does Scrum need to be Complemented with eXtreme Programming to Succeed? |

    [...] feature prioritisation needs to be reconsidered before each Sprint.  In Scrum, the Product Owner [5] is responsible for determining the most valuable features and asserting their [...]

  19. 3Cinteractive Blog - My Hectic First Week as a Product Owner |

    [...] exactly bring me down to a cool, calm, and collected frame of mind.  Overall I learned that the Product Owner role is a daily learning process that is ever changing.  I am finding myself constantly changing [...]

  20. Rick |

    To transform an organization from water-fall to SCRUM, many have push their current project manager to be Scrum Master. In my opinion, a good water fall project manager are more qualified to be Scrum Product Owner. As Scrum Product Owner required good communication skill to manage stake holder, which they were already well trained to do so in water fall methodology. A Scrum Master is like a Coach in XP who needs to be Agile in his/her DNA to be successful. Otherwise it just produces water-scrum-fall.

  21. Scrum Methodology | Frank Sun |

    [...] has three fundamental roles: Product Owner, ScrumMaster, and team [...]

  22. Agile and the important practices | Rock Paper Linux |

    [...] for managing projects. I will be writing about a couple of agile practices: iterative development, product owner, user story, sprint backlog, business value and test-driven [...]

  23. 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.

  24. 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://agileatlas.org/articles/item/large-scale-scrum-less-is-more

  25. 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.

  26. MJ |

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

Leave a Reply

Scrum Training Courses