Product Owner

ABOUT THIS CHAPTER   One of the key emphases of Agile development is to sequence delivery of functionality from highest business priority to lowest. Highest-priority stories move toward the top of the backlog for additional refinement and implementation in the near-term sprints. Prioritization is also used decide which stories to implement and which stories not to.

Prioritizing requirements has always been useful, but for Agile projects requirements prioritization becomes a more prominent focus. A few really effective techniques have been developed to support this. But first let’s take a look at the role most responsible for prioritizing requirements in Agile projects.

Product Owner

As I described in the “More Effective Agile Beginnings: Scrum” chapter, one of the most common failure modes in Scrum is an ineffective Product Owner (PO). In my company’s experience, an effective PO has the following attributes:

Domain area expertise: An effective PO is an expert in the application, industry, and customers their application serves. Their understanding of the industry provides a foundation for prioritizing their team’s deliverables, including understanding what is really required in a minimum viable product (MVP). They have the skill needed to communicate business context to the technical team.

Software requirements skill: An effective PO understands the level of detail and type of detail needed to define requirements appropriate to their specific environment. (The level of detail needed for business system requirements and medical devices are different.) The PO understands the difference between requirements and design—the PO stays focused on “the what” and leaves “the how” to the Development Team.

Facilitation skills: A strong PO can bring people together toward a common goal. Software requirements work is all about reconciling competing interests: tradeoffs between business goals and technical goals; tradeoffs between the team’s local technical concerns and larger, organizational architectural concerns; conflict between different product stakeholders; and other tensions. An effective PO will help stakeholders work through different perspectives for the sake of a strong product.

Courage: An effective PO needs to be able to make decisions from time to time. An effective PO is not autocratic but knows when to employ the paradigm of “decision leader decides” vs. “group decides.”

General personal-effectiveness attributes: An effective PO also has the general personal-effectiveness attributes of high energy level, proactive behavior for backlog refinement, leading meetings efficiently, and consistent follow-through.

This list of desirable attributes implies some aspects of an effective PO’s background. The ideal PO has an engineering background, experience in the field, and business experience, though as I mentioned earlier, with appropriate training, business analysts, customer support staff, and testers can all make excellent POs.

T-shirt sizing

As I discussed in my book Software Estimation: Demystifying the Black Art (McConnell, 2006), T-shirt sizing is a useful way to prioritize partially refined functionality based on approximate return on investment.

In this approach, technical staff classifies each story’s size (development cost) relative to other stories as Small, Medium, Large, or Extra Large. (“Stories” can also be features, requirements, epics, and so on.) In parallel, the customer, marketing, sales, or other non-technical stakeholders classify the stories’ business value on the same scale. These two sets of entries are then combined, as shown in the table below.