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 become a Scrum Alliance Certified Scrum Product Owner (CSPO) by attending Angela Druckman’s Certified Scrum Product Owner training course. All quotes in the article are sourced from the course materials.
Here’s the lowdown on who a Product Owner is and why it’s such an important role, one that often goes unrecognized and under-appreciated. Plus 10 potential pitfalls to avoid (you’re welcome).
Scrum basics
First, the course reviewed the basics of Scrum. Scrum is an Agile framework for managing work on complex products.
Scrum is a lightweight framework that limits and time-boxes work. It emphasizes completion of whole products. Scrum is structured in a way that surfaces and highlights bottlenecks so they can be quickly removed.
Scrum contains a series of practices that are used to conduct work. Requirements are broken into user stories and placed on a prioritized product backlog. The team selects stories from the backlog and organizes them into short, time-bound bodies of work called sprints. Each sprint has the goal of producing an increasingly robust working product.
The goal of Scrum is to produce the highest value for the available time and resources.
Scrum team
The Scrum team contains three roles:
- Scrum Master – Facilitates the Scrum process. Removes obstacles and ensures the team has everything needed to deliver maximum value.
- Product Owner – Represents the stakeholders. Communicates needs and acceptance criteria to the team, handles project reporting, and owns the product vision and backlog.
- Team Member – Completes the tasks. A group of cross-functional team members who deliver the work committed to the sprint.
Importance of the Product Owner
The Product Owner (PO) is responsible for the product’s overall success and represents the stakeholders. The Product Owner:
- Translates needs into actionable work items
- Defines them into User Stories
- Continuously maintains and prioritizes the product backlog
Above all, the Product Owner’s job is to promote the Agile goal to deliver the most business value possible with the given time and money.
While the Product Owner represents the stakeholders’ interests, making them happy is NOT his/her goal.
The PO must have the capability and the authority to make tough prioritization decisions. In particular, s/he must deflect stakeholder demands that don’t promote product goals and reject delivered stories that don’t meet the defined acceptance criteria.
Relationship to Scrum Master
While the Product Owner and Scrum Master support each other, the class teaches us that their roles are, by definition, “in tension”.
This dynamic balances interests to ensure that all perspectives are considered. Consequently, to maintain this balance, it’s best if they are of similar temperament.
Ten Product Owner pitfalls
The course covered all aspects of the Product Owner role, including real-world examples and hands-on exercises.
However, what I found most compelling was a discussion of some typical 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, especially in prioritization and acceptance of work.
One Product Owner working with multiple teams
On the other hand, a Product Owner serving multiple teams 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 teams. If a PO must work with multiple teams, they should be on the same or at least closely related product.
Product Owner being the direct manager of one or more team members
This is a common mistake that often results in team members over-committing to please their manager. Moreover, it can also turn the daily stand-up into a verbal status report to the manager, which then inhibits the team dialogue and self-management that are hallmarks of Scrum teams.
However, 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.
Combining Product Owner and Scrum Master roles
Many organizations don’t see why they need to fill these roles separately. But combining the Product Owner and Scrum Master roles effectively results in a traditional project manager. While this is familiar and comfortable for those who come from traditional waterfall, 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.
Consequently, many product managers are just more comfortable with a broader focus on market conditions and long-term strategy than planning the next 3-6 months of backlog and writing detailed user stories.
Situating the Product Owner in IT
Often, the business is reluctant to own the role of Product Owner, leaving IT to fill the role. Since the rest of the Scrum team is already technical, this can result in technically strong solutions that may not satisfy user and business needs.
One suggestion discussed in class for moving the role toward the business is to start inviting business stakeholders to the sprint reviews.
Seeing the working product often encourages the business to desire more participation in the solution, and eventually the business asks for ownership of the PO role.
Product Owner taking on technical team member tasks
It’s so tempting to want to help during crunch times. But there are two main reasons why it is inadvisable to for the Product Owner to take on team tasks:
- Time – Committing to additional tasks often results in the Product Owner not being able to complete his or her own work.
- 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 measure assigned to a story to assess its level of effort.
With velocity, there are several temptations to avoid:
- Expecting velocity to be continually increasing – The most optimal velocity is a predictable one, as it will enable you to commit and deliver consistently. You don’t want variability – up or down.
- Manipulating velocity – Resist the pressure to accept incomplete work for an almost-done story just to increase the velocity.
- Using velocity to compare teams or for individual performance evaluation – Velocity is a based on story points, and every team defines story points differently. Comparing teams based on an arbitrary measure simply doesn’t make sense.
Rewarding drama
Above all, 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. In fact, when it’s the exception, it can even promote team bonding and camaraderie.
But coming to the rescue, saving the day, or being the hero can also 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 incentivize a team to run everything as a crisis, so work becomes reactive instead of proactive. Continually operating in chaos mode will quickly lead to stress and burnout and significantly degrade performance over time.
Predictable, consistent teams estimate their work reasonably and only commit to what they can comfortably deliver.
Predictability is the nirvana of a Scrum team and will go a long way to help you succeed as a 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 what it really takes to be a SCRUM MASTER. Understanding the ins and outs of this vital and often misinterpreted role will help your organization take better advantage of Scrum.