Scrum Rules: Your Product Owner Can Veto the Inclusion of an Idea on the Product Backlog

The Product Owner is responsible for ensuring that the Product Backlog Items reflect and contribute to the vision of the product being built by the Scrum Team. Therefore, the Product Owner needs the authority to reject any suggestions for features, functionality or fit and finish that do not move the product towards that vision.

This authority must be based on both the depth of knowledge of the Product Owner as well as formal responsibility granted by the organization. A Product Owner that does not have this authority to veto may nevertheless be able to accomplish the same thing by putting any unwelcome ideas at the very end of the Product Backlog based on authority to order the Product Backlog. The lack of this authority to veto can lead to a product with no integrity of vision, an erosion of the Product Owner’s authority to order the Product Backlog, and ultimately an erosion of the critical separation of powers between the Product Owner and the rest of the Scrum Team (the Product Owner with authority over “what to build” and the rest of the team with authority over “how to build it”).

The easiest way to do this is to provide a distinction between proposed Product Backlog Items and accepted Product Backlog Items. Anyone who wishes to add something the the Product Backlog proposes items to the Product Owner. However, until the Product Owner accepts an item, it isn’t actually part of the Product Backlog. This system should also be transparent to stakeholders: the proposed items are stored so anyone can see what is in that state. Likewise, the accepted Product Backlog should be transparent.

A slightly more political approach is to have a policy that all Product Backlog items start at the absolute bottom of the Product Backlog. Anyone can add an item to the bottom at any time. It does not need to be accepted to be added. Only the Product Owner can order the backlog items so it is simple to then just ignore items as an effective veto. The only down-side to this approach is that it can lead to a large, hard-to-manage number of items. Since most estimation techniques that are used as part of an ordering or planning activity ask for all the backlog items to be handled, it can become either awkward to leave some out or wasteful of time to include all of them. If the list grows to large, it may force the use of an electronic tool for tracking items.

Alternatively, the Product Owner can set the expectation that all backlog items proposed need to be justified relative to the product vision and have at least a basic ROI estimation made. In this way, stakeholders suggesting items must put in a bit of work to help the Product Owner. A downside for this policy is that stakeholders may dramatically over- or under-estimate the ROI since they are not usually experts in the overall product and its marketplace. This poor analysis then may lead to missed opportunities with backlog items being rejected before the Product Owner ever sees them.

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. 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 Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…