Happy Business People In Meeting

Product Owner – The Forgotten Scrum Role

Sure, everyone wants to be a Scrum Master. It’s easily the most recognizable Agile role. Even people unfamiliar with Agile have heard of it. I mean, “Master”…right?

But what about the Scrum Product Owner?

Scrum Pr… what?

I had the opportunity to attend Angela Druckman’s training course “Scrum for Product Owners: Tools for the Agile Organization” and become a Certified Scrum Product Owner (CSPO).

Here’s the lowdown on who a Product Owner is, why it’s such an important role that often goes unrecognized and under-appreciated, and some potential pitfalls to avoid.

Scrum Basics

First, the course reviewed the basics of Scrum. Scrum is an Agile framework for managing work on complex products. Its goal is to produce the highest value for the available time and resources.

Scrum describes a series of practices that are used to conduct work. Requirements are broken into user stories, which are put on a prioritized product backlog. Stories are selected from the product backlog and organized into short, time-bound bodies of work called sprints, each with the goal of producing an increasingly robust working product. Each sprint is run using a number of prescribed Scrum ceremonies:

  1. Backlog Grooming – Refining User Stories on the product backlog to further define the requirement, flesh out the acceptance criteria, and define the level of work required to complete the story.
  2. Sprint Planning – Selecting User Stories from the Product Backlog and committing to the work to be delivered in the sprint.
  3. Daily Standup/Daily Scrum – A quick meeting for the Scrum team to connect on what will be worked on that day and where help is needed. It is the only time the whole team hears the same thing.
  4. Sprint Review – A showcase for the Product Owner and stakeholders of the work completed during the sprint. The Product Owner accepts or rejects the delivered work.
  5. Sprint Retrospective – A meeting of the Scrum team to reflect on what went well, what didn’t, and what can be done differently to improve in the next sprint.

Scrum is a lightweight framework that limits and timeboxes work and emphasizes completion of whole products. It is structured in a way that shines a light on bottlenecks so they can be mitigated quickly.

The Scrum team contains three roles:

  1. Scrum Master – Facilitator of the Scrum process; removes obstacles, and makes sure the team has everything it needs to deliver maximum value.
  2. Product Owner -– Representatives of the stakeholders; communicates needs and acceptance criteria to the team, handles project reporting, and owns the product vision and backlog.
  3. Team Member – A group of cross-functional team members who deliver the work committed to in the sprint.

The Importance of the Product Owner

The Product Owner is responsible for the overall success of the product and functions as the representative of the stakeholders: translating needs into actionable work items, defining them into User Stories, and continuously maintaining and prioritizing the product backlog.

The Product Owner’s primary job is to promote the Agile goal of delivering the most business value possible with the time and money given. It is NOT to make Making stakeholders happy is NOT a goal of the Product Owner.

The Product Owner must have both the capability and the authorization to make tough prioritization decisions. In particular, the Product Owner must be able to deflect stakeholder demands that don’t promote the goals of the product and to reject any delivered stories that don’t meet the defined acceptance criteria.

While the Product Owner and Scrum Master support each other, the class teaches us that their roles are, by definition, in “tension”. This dynamic provides a balance between interests in order to assure that all perspectives are considered. Therefore, they should be of similar temperament so the team maintains balance.

Product Owner Pitfalls

The course covered all aspects of the Product Owner role, including real-world examples and hands-on exercises. What I found most interesting was a discussion of some typical shortcuts and potential mistakes to avoid when finding a Product Owner and/or operating as one:

Designating more than one Product Owner on a team
There should be one, and only one, Product Owner for a given product or team. Multiple Product Owners can cause conflicts and confusion on the team, particularly in prioritization and acceptance of work.

One Product Owner working with multiple teams
On the other end of the spectrum, the Product Owner can quickly become overwhelmed managing multiple backlogs, multiple sets of stakeholders, multiple sprint reviews, etc. The recommendation is to keep it to 1-2 maximum, and if you must assign multiple teams, they should be on the same or at least closely related product.

Product Owner being the manager of one or more team members
This is a common mistake that organizations should try to steer clear of, as it results in team members perpetually over-committing to please their manager. It can also inhibit the team dialogue and self-management that are hallmarks of Scrum teams, as the daily standup morphs into a verbal status report to the manager.

The one exception mentioned in class is the case of an operations team, where it is most effective for the operations manager to be the product owner.

Trying to fill both Product Owner and Scrum Master roles with one person
Many organizations don’t see why they need to fill these roles separately. Combining the Product Owner and Scrum Master roles effectively results in a traditional project manager, which is familiar and comfortable for those who come from traditional waterfall organizations. This isn’t necessarily a bad thing in and of itself, but it is no longer Scrum or Agile. To really take advantage of Scrum, the roles need to be separate, as they have separate purposes in providing a very necessary balance of interests.

Filling the role with the Product Manager
While their functions are similar, product managers generally operate at the strategic level, whereas Scrum Product Owners on a Scrum team are far more tactical. There are, of course, always exceptions, but many product managers are more comfortable with a broader, 40,000-foot level focus on market conditions and long-term product strategy, as opposed to the 10,000-foot level where the Product Owner is planning the next 3-6 months of backlog and writing detailed user stories.

Situating the Product Owner in IT
Often, the business organization is reluctant to take on the role of Product Owner, leaving IT to fill the role. Since the rest of the Scrum team is already on the technical side, this can result in bias toward technically strong solutions that may not satisfy user and business needs.

One suggestion discussed in class for transitioning the role toward the business is to start inviting business stakeholders to sprint reviews. Seeing the working product often encourages the business to desire more participation in the solution, which eventually leads to the business asking for ownership of the product owner role.

Product Owner taking on technical team member tasks
It’s so tempting to want to help during crunch times. There are two main reasons why it is inadvisable to for the Product Owner to take on tasks of the development team:

  1. Time – Committing to completing additional tasks often results in the Product Owner not being able to complete his or her own work.
  2. Conflict of Interest – The job of the Product Owner is to accept or reject completed work based on the acceptance criteria. Evaluating your own tasks creates a conflict of interest, or, at least, the appearance of one.

Accepting work that doesn’t meet the definition of “done”
Product Owners face enormous pressure to accept work that doesn’t meet acceptance criteria. Often, the option to split a task, or define bug fixes as further stories for the backlog, looks very tempting. Don’t do it. A story is either complete or not. If you accept incomplete work once, you have set the precedent for the team to compel you into acceptance every time.

Velocity expectations
Velocity is the average amount of work a team completes in a sprint. It is measured in story points, an arbitrary number assigned to a story to assess its level of effort. With velocity, there are several things to consider:

  1. Expecting velocity to be continually increasing – This is a very common mistake. The most optimal velocity is a predictable and consistent one. The number isn’t important. Your life as a Product Owner will be much simpler with a team that has a predictable velocity, as you’ll be able to commit and deliver consistently.
  2. Manipulating velocity – The Product Owner must resist the temptation to accept incomplete work or give “partial credit” for an almost done story in order to increase the velocity.
  3. Using velocity to compare teams or for individual performance evaluation – Velocity is a based on story points, and every team defines story points to be what works for them – one team might use 1-10, another team might use 1k-10k. Comparing teams based on an arbitrary measure is never a valid comparison. Again, you want a team to be consistent in the number of their story points they can complete in a sprint. The actual number is irrelevant.

Rewarding drama

Product Owners do not need drama – their success depends on being able to accurately and reliably plan, communicate, and deliver. Sure, we all have a crisis situation now and then where everyone comes together and makes it happen.

When this is the exception, it can even contribute to team bonding and camaraderie.

But coming to the rescue, saving the day, or being the hero can be intoxicating and addictive. Beware of sliding into the habit of scrambling to meet deadlines and pulling all-nighters. Even a small reward for this behavior can give a team the incentive to run everything as a crisis, where work becomes reactive instead of proactive. Operating in chaos mode will quickly lead to stress and burnout, significantly degrading performance over time.

Predictable, consistent teams estimate their work reasonably and only commit to what they can comfortably deliver. This behavior is the nirvana of a Scrum team and will go a long way to help you be successful in your role as Product Owner.

So now you know. If you’ve been thinking about getting into Scrum, or if your organization is looking to build a Scrum team, check out the role of Product Owner. Understanding the ins and outs of this vital and often-misinterpreted role will help your organization take better advantage of Scrum.