Solid Product Owner Crucial for Scrum Teams
By: Jabulani Leffall
Tags: Scrum Product Owner, Scrum, Agile Coaching, Agile Methodology, Agile Development

Words are important. Words have power, words are symbols. We call it spelling because words casts as spell on the way we think. In this vein we think of Scrum, the most commonly used Agile framework. We think of the word master and we think of one who commands an art or craft — mastery.

So naturally it would stand to reason based on our Agile lexicon that the set of accountabilities for Scrum Master make the Scrum Master the most important role in Scrum right?

Wrong.

The answer is that are no “most important” roles as peers in the Scrum world have pointed out to me. In an ideal world, the Scrum framework is based on one one unit, no ranks, no bosses, only a team leading itself.

That said I believe it’s the Product Owner whose role is the most crucial to practicing Scrum in the correct and most sustainable way.

To wit, on a team you can trade out Scrum Masters if they understand Scrum. Someone from the development team can step into the Scrum Master role if need be. Yet you can’t trade out Product Owners as easily.

The Scrum Guide defines the Product Owner as “accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

The Product Owner is also, according to Scrum guidelines and folklore, the so-called voice of the end users and collaborates with internal and external stakeholders. Internal stakeholders can include everyone such as middle managers and executives at program and enterprise levels as well as department stakeholders such as customer success or customer service; sales and marketing teams.

While the Scrum Master must make sure all lines of communication are open with these stakeholders and all impediments are removed, the Product Owner is accountable for defining and refining business requirements. This could include clarifying epics, user stories and product backlog items for Scrum Teams to evaluate and commit to as one entity.

For the Product Owner, this is no easy task. Now a peak at what the Scrum Guide specifically says about Product Owner responsibilities:

● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;

● Ordering Product Backlog items;

● Ensuring that the Product Backlog is transparent, visible and understood.

As a Scrum Master and Agile Coach, my anecdotal evidence across multiple organizations suggests that the biggest pain point is often product ownership. In my experience, many organizations expect the Scrum Master to do the tasks listed above or expect the Product Owner to do them alone without guidance, coaching and collaboration from the Scrum Master and Scrum Team.

This is where Product Owners who understand Scrum and trust their teams represent the most vital aspects of Scrum. The arduous task of Product Owner can most often make or break a Scrum Team and this is also the role that is most likely to lead to bottlenecks, scope creep, and the team faltering if not executed succintly.

As the Scrum Guide says: “The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”

While the Product Owners are only as powerful as their requisite teams and the Scrum Masters who coach and protect them, it’s the Product Owner who must be solid and resolute enough to negotiate with stakeholders and customers.

Hence Product Owner travails can be the biggest on the team for the following reasons:

They are overwhelmed by the mandate of Scrum

They aren’t receiving clear product road maps from upstream,

They are conflating a different job title (which also may be Product Manager or Project Manager/Coordinator) with the Scrum role of Product Owner.

So many Product Owners who have another job title and those who have the actual Product Owner job title often find it difficult to context switch to correctly fit Scrum guidelines. This is where a supportive team comes into play.

The caveat, however, is that in this way, the Scrum Master can only coach but not play the role of Product Owner.

This brings me to the most salient point in our world of words, titles and symbols, which shift with the prevailing winds of thought. Scrum is designed specifically create the most value in the least amount of time and not chiefly to make sure the “project/work gets done.” The Product Owner must understand this and the Scrum Master must coach this into fruition. The Product Owner must also be open to that coaching.

In Scrum, the Product Owner is a value creator. Without a viable, consistent and focused Product Owner, all a Scrum Master or Scrum team can do is repeat the Scrum Events over and over again. There is a danger of repeating sprints over and over again without goals or purpose or value for that matter.

These potentially chaotic and directionless cycles can lead to technical debt and low morale without a solid Product Owner or the outright absence of Product Ownership.

I’ve seen both of these things happen on teams where I was Scrum Master. In one case there was the lack of overall ownership and the reluctance to context swtich into an Agile mindset when it came to daily stand ups and backlog refinement. In another case there was a Product Owner who wanted to own everything. Further still, in other cases, there was little to no ownership at all — leaving the team at the mercy of OBE (Overcome by Events).

The most compelling fact facing all Product Owners is that most upstream stakeholders usually aren’t as educated on Agile Frameworks as Scrum or Scrumban team members are. The Product Owner is the voice of these demanding and often flippant, detached and demanding customers and end-users.

That said, the Product Owner’s role per the Scrum Guide is set in stone. It’s often a rock and a hard place scenario for the Product Owner, which makes the PO the most essential Scrum role in my opinion. It’s my duty as a Scrum Master to serve the Product Owner with an empathetic yet evidence based approach.

The word is out, the challenge is built in.

Do you want to write for Serious Scrum or seriously discuss Scrum?