The New New Product Owner

[TODO: Fix Links.  For more info, see:  ScrumCrazy.com is Moving…]

Please consult the current Scrum Guide for the definition of Scrum. This article is simply a supplemental musing, intended to be in line with the Scrum Guide, but focusing more on describing the Product Owner role in Scrum from the Product Owner’s point of view. Reading the Scrum Guide is a must for someone playing the Product Owner role, and is highly recommended for anyone who will be interacting with a Scrum Team in any way (including product management, line management, Scrum Team members, etc). So… Read the Scrum Guide! It’s only 16 pages!

Introduction

One of the high impact inspirations for Scrum was a paper called “The New New Product Development Game”. In it, the authors detailed a completely different way to go about product development, and a vastly more successful way I might add, than past attempts at product development. This paper inspired the co-creators of Scrum, and shapes many aspects of Scrum.

It’s now 2015, and in the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Product Owner role that have far reaching implications. So, in this article, I attempt to describe what I believe to be “The New New Product Owner” role in Scrum.

New Video! See Charles give a presentation based on the content of this article!

Presentation slides

Building the “Right” Thing

In executing Value Driven Development, the Product Owner must consider the focus areas of:

• Product Value Maximizer
• Product Visionary
• Product Marketplace Expert
• Product Release Decision Maker
• Lead Facilitator of Key Stakeholder Involvement
• Other Product Owner role Considerations

Product Value Maximizer

The Product Owner is the product value maximizer in Scrum. Value, as defined in a Scrum context, is the financial benefit an organization receives or might receive by creating and releasing the product under development. For the more rare case that an organization is not seeking financial benefit, such as charities and nonprofits, then value in a Scrum context is a “societal benefit” instead of a financial benefit.

Complementary Practice: Ideally, the Product Owner has Profit and Loss accountability for the product since they are the product value maximizer. Obviously, they should also have the associated empowerment that goes along with the P&L responsibility. For more good info on how best to fulfill the Product Owner role, see the first section here.

A “Complementary Practice” is an optional practice that is not part of the Scrum framework, but is sometimes used in addition to the Scrum Framework. Please note well that complementary practices may only work well for a limited set of contexts, so your mileage may vary. As such, try them, then don’t forget to inspect and adapt accordingly!

Note here that Scrum is very heavy on viewing a software system as a product, and not a project. This “product point of view” has all sorts of wide ranging ramifications, both in the large and the small, that are beyond the subject of this article.

A good Product Owner will evaluate the outcomes of the software development efforts as a way to close the value feedback loop. The Product Owner orders the backlog to optimize value, but it’s an estimated value, so it’s important to see if that estimate or value prediction is actually coming to fruition. An excellent way to assess if your product is optimizing value is to gather and use the metrics described in the EBMgt Guide here:

http://www.ebmgt.org/Evidence-Based-Management

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

Product Visionary

The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs. The PO should communicate and re-iterate this vision early and often, reminding all involved of how to help maximize value. Utilizing the underlying empirical product planning features of Scrum, the PO should also be ready to make strategic pivots for the product vision whenever there are significant changes in how value can or likely be captured. This vision is brought to life in a more tactical way, via the Product Backlog and iterating towards that vision every Sprint.

Product Marketplace Expert

The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster. Note here that the Product Owner may or may not be the one doing the legwork of gathering the marketplace data, but they should definitely be aware of said data/research.

Additionally, the PO should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

The Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Refinement and in Sprint Reviews.

Product Release Decision Maker

The PO is the one and only person who can decide whether to release the latest increment of the product. Additionally, the PO is responsible for assessing and communicating progress towards a goal or release, at the least, every Sprint in the Sprint Review. Part of this progress communicating specifically involves tracking the amount of work remaining toward a goal, and updating that amount of work remaining every Sprint in the Sprint Review. In this way, the Product Owner keeps all involved informed of the progress of the product.

In order for value to actually be captured, a release of the product must occur. As such, while Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind. Looking at it another way, the sooner you release, the sooner you can start capturing the value created by the product.

Another factor in the release decision is whether your customers can actually absorb your frequent releases. Most customers approach this upgrade decision using a common sense method of weighing the costs and benefits of the upgrade(new increment). This is all the more reason to make sure that your releases are of the utmost value, and offer relatively low absorption costs. Regardless of the benefits and costs, some customers will still be constrained, so this constraint should be a consideration when deciding how often or whether to release. Scrum is designed to enable frequent releases and value capture, but does not mandate them. To Release or Not Release, that is the question… for the Product Owner.

As another part of the Product Owner’s “release decision maker” responsibilities, the Product Owner should work to understand the Scrum Team’s Definition of “Done,” at least at a basic level, so that she may have transparency into the releasability of the product increment. Ideally, the Definition of “Done” mirrors “releasable” to end users. For more information on the Definition of Done, see the relevant section in the Scrum Guide.

Lead Facilitator of Key Stakeholder Involvement

In order to maximize value, the PO should identify the key stakeholders for the product, and involve them as necessary throughout the development effort. Key stakeholders are typically customers, purchasers, users, and the people that fund the product’s development. These people may be internal or external to the organization. In specific, the PO is responsible for making sure that the key stakeholders attend and interact in the Sprint Reviews, but really the stakeholders can be involved with the Scrum Team any time where it’s valuable to have the stakeholder input.

Complementary Practice: The best Product Owners come from the “business side”, or stakeholder community. For more information on who should play the Product Owner role, see here .

Inherent in the role of facilitating key stakeholder involvement is weighing and balancing the (likely) differing viewpoints of multiple stakeholders who might have varied interests in the product. The Product Owner’s responsibility is to maximize the value of the product as a whole, and this will involve an intelligent balancing of interests. While the PO is the lead facilitator of stakeholder involvement, the PO need not and probably should not become a controlling gatekeeper or bottleneck between the Scrum Team and stakeholders. They simply act as a “lead facilitator.” Often times, the PO will connect key stakeholders with Development Team members to refine the backlog or get product feedback. Just be sure to have a way to loopback the results of those collaborations back to the PO to keep them informed.

Product Backlog Management Leader

This topic is worthy of a section of its own. See below.

One PO Can Do it All!

The PO is one person, and for a given product, there is one product backlog, and one Product Owner, regardless of how many Scrum Teams work on a product. One PO can do it all.

Complementary Practice: In order for one PO to “do it all”, often times, when a product grows, it is helpful to integrate customer interaction into the product itself, via customer forums and customer feedback mechanisms. In addition, much information about the product’s usage index(% of features used most often) can be found by doing simple database queries or by installing simple monitoring mechanisms into the software itself. A good PO will collaborate with the Dev Team to build this functionality into the product via inserting those customer feedback mechanisms into the product backlog as features.

Complementary Practice: In order for one PO to “do it all”, often times, when a product grows, it is quite possible that the PO will get help from other Product Managers and others in the organization who interact regarding the customer facing activities and knowledge of the product marketplace. While it is fine for the PO to be aided by the aforementioned people, it is *NOT* acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties, especially the Scrum Team facing duties.

For another way to help the PO have the time needed to play their role well, be sure and see the “Scrum History” section under “Product Backlog Management Leader” below.

One important thing to note about the Product Owner role is that there might very well be much more involved in Agile Product Management for a product than being a Product Owner. In fact, many Agile Product Management activities are not connected directly to Scrum at all. Said another way, Scrum is not attempting to take over all of the activities related to Agile Product Management.

Other Key Product Owner Role considerations

The PO and only the PO has the authority to cancel a Sprint before the Sprint is over, largely because the PO is the one responsible for assessing and maximizing value. The PO can be influenced by others, but only the PO can make this decision. Due to the short duration of Sprints and the trauma that a cancellation generally causes, cancelling a Sprint rarely makes sense. It would only make sense if the company or market conditions drastically changed in a way that made the current Sprint Goal completely valueless. On the rare off chance a Sprint cancellation seems appropriate, see the Scrum Guide for more details on how to handle canceling a Sprint.

In order to effectively be the product value maximizer, the entire organization must respect the PO’s decision authority via the PBL. In fact, in Scrum, the Dev Team is not allowed to work on or act on what anyone else says with respect the product – they can only implement what the PO asks them to.

One of our company’s core strengths is coaching and consulting for Product Owners and Scrum Teams. See more info on our coaching services.

Building the Thing “Right”

Effective and Active Scrum Team Collaborator

Collaborating with the Development Team

The Product Owner should be highly available for clarifications, and also help the Development Team respond to challenges when needed. One of these challenges is the decision to add or remove scope to an already in progress Sprint – this is a collaborative decision made between the Product Owner and the Development Team.

The Product Owner is very careful to respect the self-organization of the Development Team and of the Scrum Team as a whole. While the PO has a very specific role to play in guiding the Scrum Team, their primary responsibility and authority revolves around the product. The PO’s role with respect to the *process* is as a Scrum Team member, and as such, one who respects the Scrum framework.

The Product Owner will help guide the sprints by bringing business/value objectives to Sprint Planning in order to collaborate with the Dev Team on crafting a Sprint Goal.

The Product Owner will also heavily collaborate in an ongoing way with the Development Team on upcoming sprints via Product Backlog Management, as described below.

In addition, the Product Owner will collaborate in an ongoing way with the Development Team on the current sprint’s work, answering questions, making clarifications, and negotiating scope and value tradeoffs as more is learned via the work of the in progress Sprint.

Complementary Practice: In order for one PO to “do it all”, often times, it is quite possible that the PO or Scrum Team will bring in stakeholders, customers, users, subject matter experts, and others, into the Sprint development activities to help the Development Team build a valuable product. The best Product Owners act as “matchmakers” between Development Team members and those outside the Scrum Team that can help to maximize feedback and product value. While it is fine for the PO and Scrum Team to be aided by the aforementioned people, it is *NOT* acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties, especially the Scrum Team facing duties. The PO still remains accountable and responsible for maximizing the flow of product value, as well as the rest of their associated Scrum Team/PO duties.

Collaborating with the Scrum Master

A good Product Owner will gracefully accept coaching and guidance from the Scrum Master regarding Scrum, Product Backlog techniques, and empirical product development. A good Product Owner will accept this guidance *without* resorting to delegating their Product Owner responsibilities to the Scrum Master. There is a saying, “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.” The point of the Scrum Master’s guidance is for the Scrum Master to teach the Product Owner to fish, not to give her the fish.

The Product Owner may work with the Scrum Master to help remove impediments, whether they be team facing, organization facing, or market facing. The Product Owner might utilize the Scrum Master to facilitate events as requested or as needed.

The Product Owner will work in concert with the Scrum Master to utilize Scrum correctly and advantageously, and try to never been seen as subverting or disrespecting the Scrum framework. When something about Scrum frustrates a Product Owner, she should consult the Scrum Master for ways to implement the Scrum framework in a way that is effective.

Finally, as a full-fledged Scrum Team member, the Product Owner should participate in all of the responsibilities as assigned to the Scrum Team in the Scrum Guide.

Collaborating with those outside the Scrum Team

In concert with Scrum Master, the Product Owner may help educate those outside the team to maximize the value of Scrum via upstream adoption and wider organizational agility. In addition, the Product Owner will collaborate with those outside the Scrum Team as described above in the section on “Value Driven Development”.

Product Backlog Management Leader

The Product Backlog is the requirements vehicle that is utilized by the Product Owner to capture the value of the possible product. The Product Owner is solely responsible and accountable for the decisions in the Product Backlog. Having said that, who does the work of updating and managing the Product Backlog is a collaboration between the Product Owner and the Development Team. The Product owner might do the vast majority of Product Backlog Management, or they might have the Development team do the vast majority of the work of Product Backlog Management, or maybe some strategy in between. Regardless of who does the legwork, the Product Owner remains accountable and responsible for leading the Product Backlog Management effort.

Scrum History: Previous versions of Scrum assigned the Product Backlog Management *and* associated legwork entirely to the Product Owner. In practice, this tended to scare away true Agile Product Managers and encouraged the growth of “Product Owner Proxies” (often of the IT Business Analyst variety) instead of fully empowered and fully marketplace/business knowledgeable Product Owners who interacted more directly with customers. This proxy anti-pattern greatly reduced a Scrum team’s ability to deliver products of the highest possible value. As such, Scrum was changed to allow the Product Owner to have the Development team do some or all of the legwork of product backlog management. By delegating said legwork, the Product Owner can also more effectively work on products that require the teamwork of multiple Scrum Teams, allowing the Product Owner to focus more closely on Value Driven Development and customer feedback on the product.

A very important part of Product Backlog Management is the ordering of the Product Backlog in such a way as to optimize the capture of value. This ordering re-emphasizes the role of the Product Owner as the value optimizer of the product, who should be attempting to do Value Driven Development as discussed above. While the PO is not the only person who may influence the ordering of the Product Backlog, the Product Owner has the “last say” on the order of the Product Backlog, and those wanting to change the order of the Product Backlog have to influence the Product Owner to do so.

The Product Owner will work with the rest of the Scrum Team on choosing and optimizing the techniques used to represent Product Backlog Items. User stories are a fairly common technique for representing Product Backlog Items, but other techniques can be used instead of User Stories. For instance, a team can use scenarios, Use Cases, acceptance tests, and other techniques as well. The Product Backlog might even contain a heterogeneous mix of the above. Also, don’t forget, that the legwork of managing the Product Backlog might be fully delegated to the Dev Team, so it is quite possible that the Product Owner might not ever create or write a User Story or Product Backlog Item. Certainly the Product Owner owns the decisions of the Product Backlog details, but they might not do the legwork of capturing said details.

Regardless of the technique used to represent them, all Product Backlog Items must:

• represent a requirement for a change to the product under development, and
• have all of the following attributes: description, order, value, estimate.

For further definition regarding the Product Backlog and Product Backlog Items, see the appropriate sections in the Scrum Guide.

One of our company’s core strengths is coaching and consulting for Product Owners and Scrum Teams. See more info on our coaching services.

Product Backlog Refinement

One other key responsibility of the Product Owner is collaborating with the Development Team to do Product Backlog Refinement (Formerly known as Product Backlog Grooming). Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Complementary Practice: While Scrum does not specify how or when Product Backlog Refinement is done, some Scrum Teams find it useful to do whole team refinement weekly for a couple of hours, while other teams find it useful to do it in smaller chunks after the Daily Scrums. Dabble around and experiment with your team to see what works best. Inspect and Adapt!

Note well that the refinement practice focuses on the Product Backlog Items for upcoming Sprints, not the current Sprint in progress. Obviously, though, it is certainly fine for the Product Owner to add detail and clarification to the current Sprint’s work as well, but by that time, those Product Backlog Items are no longer on the Product Backlog, because they are now on the Sprint Backlog. The top of the Product Backlog should include some items that are well refined, actionable, and ready for selection in Sprint Planning. These ready items should also be sized such that they are able to meet the Scrum Team’s Definition of “Done” within one Sprint.

Complementary Practice: Many Scrum Teams find it advantageous to always try and have enough Product Backlog items well refined and ready to fill the next 2 Sprints beyond the current sprint. Doing so also helps highlight unknowns with enough lead time to get the unknown resolved before work on the item begins.

For more definition around Product Backlog Refinement, see the relevant sections in the Scrum Guide.

The Product Owner in the Sprint Review

Related to both Product Backlog Management and Value Driven Development, the Product Owner is a vital leader in terms of getting feedback from the key stakeholders in the Sprint Review. The Sprint Review is not *just* a demo, but it definitely includes a demo of the product increment. Like other Scrum Events, the Sprint Review is an extremely vital “inspect and adapt” feedback loop whereby the Scrum Team and key stakeholders collaborate on how to make the product ever more valuable. During the Sprint Review, this feedback should be immediately incorporated into the Product Backlog. Additionally in the Sprint Review, the Product Owner discusses the Product Backlog as it currently stands, and collaborates with all present on the current ordering of the Product Backlog. For feedback and changes that affect the top of the Product Backlog, it’s important to make some immediate decisions since a new Sprint will be starting very soon.

Complementary Practice: Because the Product Owner is so pivotal in the Sprint Review, some teams find it useful to think of the Product Owner as being the “lead emcee” of the Sprint Review. This helps to keep the focus on value, and helps keep the spotlight on the important of the Product Owner in terms of the leading the Product Backlog management effort.

For the Product Owner to succeed, the entire organization must respect the Product Owner’s decisions, and this includes the decisions as contained in the Product Backlog. In fact, in Scrum the Development Team is not allowed to work on or act on what anyone else says with respect to the product.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

Conclusion

As you can see, the Product Owner is a powerful and vital collaborative role in Scrum. However, as the saying goes, “with great power comes great responsibility.” Many organizations tend to overlook the power of the Product Owner in terms of capturing value for the organization. An empowered Product Owner can be thought of as a mini-CEO of the product. To give the Product Owner role any less respect and time commitment can completely choke an organization’s ability to reap value from the software product in a globally competitive marketplace.

One of our company’s core strengths is coaching and consulting for Product Owners and Scrum Teams. See more info on our coaching services.

Other Useful Links

Professional Scrum Product Owner certification(PSPO I) study tips