Super Sponsor

Super Sponsor

The product owner is the voice of the customer and performs a significant of a number of activities, including acting as a conduit/facilitator for communication between the team and the outside world.  Other activities include: defining and elaborating stories, prioritizing the backlog and accepting work when the team completes a story.  The product owner’s role is related or influenced by the sponsor’s roles (sometimes known as executive or project sponsor).  The sponsor is the person that has overall responsibility and accountability for a piece of work.  The sponsor champions the project based on whether the work fits the business’s needs and overall strategy, finds and secures the budget and has the overall responsibility for the work to deliver the promised value. This is true even though he or she will probably never write a line of code or test.  Sponsors empower the product owner to act for them on a more tactical basis.  A comparison of how the sponsor’s typical roles translate to the product owner is shown below: (more…)


As we have seen, product owners act as a conduit between the business and/or customers and the team. The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner participates in writing the acceptance criteria for user stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality and occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on a continuous basis in order to guide the work and the culture. Adoption of acceptance test-driven development (ATDD) is an excellent method of instantiating the product owner’s role in both shaping the vision for the team and influencing the quality of the work a team delivers. (more…)


Product owners play a pivotal role in all Agile projects. This is true whether a product owner exists or not. Since the role is so critical it should be easy to define the role of product owner. However, most definitions tend to quickly devolve into a list of responsibilities that depend on implementation and scale.  One of the most critical and often most variable roles of the product owner is that of the interface between the team and the outside world.  The outside world includes users, customers, stakeholders, sponsors, and sometimes other product owners and teams. We can visualize the interface role on a continuum that on one end includes the product owner acting as a highly structured conduit for information from outside the team to a facilitator of conversations on the other end of the continuum.   (more…)

XP Explained

This week we begin getting into the proverbial weeds of Extreme Programming by tackling chapters seven and eight in Kent Beck’s Extreme Programing Explained, Second Edition (2005). Chapter 8 changes gears and provides advice on how to get started with XP.  Beck suggests that there is no single place to start for everyone. Where you start depends on where you are beginning.  Chapter 9 provides a list of corollary practices that build on the primary practices discussed in Chapter 7. (more…)

little boy building a block tower

The bigger the project, the more complicated the role of the product owner gets.

The Product Owner (PO) role in organizations that are scaling up Agile projects requires not only nuances how the role is applied but also requires refocusing the typical activities in the role (however this does not mean that they don’t they get out of buying pizza or other relevant food occasional).  The primary responsibilities of a scaled product owner are: (more…)

ornate astronomical clock

The greater the scale, the more complex the connections.

The product owner plays a pivotal role in an Agile project. That role is more complex as Agile projects are scaled and applied to new scenarios. Exploring three classic project types that most software organizations have, is a useful approach to exposing the potential nuances in the role of the scaled product owner (PO). (more…)

Less is more.

Less is more.

In terms of product owners, less is more. Any solution to the complications of scaling the product owner role for a specific piece of work should keep the product owner activities in the hands of a single person. For a single team, a single product owner should prioritize the backlog, and the team should hear the voice of a single product owner. However, as projects grow, eventually there will simply be too much for a single product owner. There will just be too many teams for a product owner to be effective. In that case, there are a number of techniques that can be used mitigate the complications so that the teams can tackle a larger effort.

  • A guidance team is a group of stakeholders that provide guidance to a product owner or group of product owners. A guidance team is also a ready-made pool of SMEs to provide product depth to the development team(s) as they flesh out, test and build functionality. The guidance team is conceptually similar to the classic steering committee used in many organizations as a governance tool; however the focus is on guiding the functional evolution of the project or product rather than acting as a mechanism to control the budget or to monitor status. The guidance team is a mechanism to consolidate guidance to a product owner or owners when there are multiple external constituencies. External constituencies can reflect the needs and wants of internal applications, functional department (eg marketing or accounting) or external customer groups.
  • Product management groups are like a specialized form of a guidance team that often exists in organizations that create products that are sold or are consumed by customers outside of the company. Typically, product management is a powerful force within product-oriented companies, and acts as the voice of the customer. Product management often guides product owners by developing an overall product roadmap that provides product owners, development and exteral customers with an understanding of how they intend the product to evolve. Roadmaps tend to be more specific in the short-term while more aspirational in the longer term. Note: Product owners are often members of the product management group.
  • The best ratio of scrum masters to product owners is 1:1. This increases the possibility of a close bond between the people playing the two roles. Every additional scrum master added to the equation requires the PO spread his/her attention and increases efficiency loss caused by switching between teams. One common coping mechanism in scenarios where a PO interfaces with multiple scrum masters is for the PO to be responsible for a single backlog. The product owner to backlog ratio of 1:1 provides an anchor for the PO’s attention. The anchor of a single backlog reduces the amount of overhead a bit so that a PO can support a few teams. The vagueness in the statement is intentioned as business and technical complexity and personalities affect whether a PO can interact with multiple scrum masters effectively.

Interactions between product owners and stakeholders, teams, scrum masters and even other product owners are part and parcel of how product owners work and a path for them to help to facilitate the delivery of value. As projects are scaled, the product owner’s role gets more complex. Finding a path to mitigate the complexity is rarely straightforward. Every organization adopts techniques that they feel will generate the most value by balancing overhead with outcome.