All you need to know about the role of a Product Owner in Agile

“Simplicity is the ultimate sophistication.”- Leonardo da Vinci

Overview

At the basement of the West Wing of the White House, a 5,525 square foot conference and intelligence management center, commonly known as the ‘Situation Room’ was buzzing like a beehive. The President is seated in the central chair. To the president’s left, there are some big kahunas including the secretaries of state and defense, the national security adviser and the CIA director. To the right are a bunch of Generals. Invariably, in the outer ring of the room, there are a whole bunch of people, much younger. 

They had the big binders and they're doing stuff and taking notes — and those are the people who are actually doing the work. The situation is the capture of one of the most notorious criminals, the world has ever seen. Naturally, everyone in the inner ring had given their two cents and were looking upon at the President to take the final call. Suddenly the President leaned across, pointed to someone in the back and said, “You, what do you think young lady?”  What the young lady answered went a long way in assisting the President to make the final decision. 

The same situation applies to a Scrum Product Owner chairing a sprint planning meeting, wherein the chief architect pitches in a spike to do a particular PoC. Ultimately, though, the Product Owner, just like the President, makes the call in terms of what the sprint goal will be but the Product Owner may say to the team or business analyst “do you want to talk to my lead designer of Login & Registration, for information on how that part of the system works. How about environment availability?” Very relatable, huh?!

In either situation, the trick was, to be able to ensure people are not telling you just what ‘YOU’ want to hear but to deliberately reach outside the bubble of the obvious decision-makers’ in order to get a holistic view. 

Who is a Product Owner? 

As mentioned in the Scrum Guide (Nov’17 version authored by Ken Schwaber & Jeff Sutherland), the Product Owner is accountable for increasing the value of the product resulting from the work of the Development Team. How this is achieved may differ extensively across companies, Scrum Teams, and people. Being the key stakeholder of the project, the Product Owner needs to have a clear vision for how the product needs to shape up and then ensure that every sprint has a sprint goal, which is in line with the overall product vision. Believe me, it really helps.

The role requires an individual with certain skills and traits, the need to be business savvy possessing excellent communication skills. However, though, the primary need is to be available to his or her team full time. The best product owners not only show commitment by doing whatever is necessary to build the best product possible but at the same time are being actively engaged with their teams, day in and day out.
 

Figure 1: Scrum Product Owner Responsibilities 

Creating and Managing a Product Backlog

As per the scrum guide, the Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. However, quite often, this is misunderstood. Should the Product Owner be the ONLY person, writing all the items on the Product Backlog? Well, the short answer is a big ‘NO’. Product Backlog is dynamic and constantly evolves in “an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items”. 

Believe me, creating the product backlog is the easier bit. Prioritizing, optimizing & overall management are the tricky bits. Something like the below image.

Figure 2: A comic depiction PBI prioritization

(Cartoon courtesy: YouTube channel - Top 10 Current Affairs)

Product Owners should work closely with their Development Team to create items for the Product Backlog and order them to maximize the value of work done by them. Development Teams, on the other hand, should proactively seek this out as well by offering suggestions for both items on the Product Backlog as their ordering.

“Writing a novel is like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.” - Novelist E. L. Doctorow

Much like your trip, a product backlog should also work in a similar fashion. Mike Cohn uses rocks to illustrate the benefit of large things further down a backlog. He quotes “I can see a pebble or a zen garden a few feet in front of me. I can’t notice a pebble that is a mile away. But I could notice Stonehenge a mile away.” Very apt and true! 

Just like defining business value on user stories, you should define values on technical debt items. Some are pretty clear (if we don't upgrade to the new version of an app, the application will come to a screeching halt), but others, like refactoring efforts, are much harder to quantify. Bugs should be something that a product owner should be prioritized along with stories. From my experience, most of the product owners I have worked with understand the need for this and realize that if they don't incorporate it, it is eventually going to come back to bite them, possibly to the point of having to do a full tech debt sprint which will hurt their credibility with the end-users.

Prioritize and Optimize

“What is important is seldom urgent, and what is urgent is seldom important” - President Eisenhower

While we all acknowledge the fact that Agile (scrum) is still about focusing on delivering value in the short term/iterations, we also need to ensure that we just don’t want to become shortsighted about it. Not especially if you are the Scrum Product Owner. A good PO will like to use the concept of product themes/features/epics or just an idea of focusing for a period of time (maybe a month, or a quarter) on a specific aspect for a product. This can help guide feature prioritization and be a great communication tool for both the scrum team and PO. 

This activity of "Thinking Big & Acting Small" will allow the Product Owner to have a clear vision on the medium to long term objective of the product, and at the same time focus on one sprint at a time in more detail. A good product owner will be careful to consider both the importance and the urgency of product backlog items when prioritizing work for the team while a great PO focuses on making sure that the product is going in the right direction in terms of business and will align with current/ future market and business needs. 

Figure 3: A comic depiction of the impact of a Product Owner

(Cartoon courtesy: www.implementingscrum.com)

The PO’s contribution to the Scrum Team?

The below table depicts various points about how a Product Owner will contribute either directly or indirectly to the activities within a Scrum Team. At each stage, it is important for a PO to ask the right questions to the team. The questions (if feasible) should be designed in such a way that they uncover any disagreements that the team may have.

Figure 4: How a Product Owner can help at various stages of the iteration

Asking the right questions

Powerful questions are one of my favorite tools. A lot can be achieved by asking the right questions, with the intent that the PO is not the solver, but a catalyst for thinking, inclusion, etc. Questions need to be contextual. Concepts such as exploring options, increasing focus, removing waste, improving transparency, and adding value are what is important. There are no simple solutions to complex problems. Critical thinking within the system and situation is what is needed.

However, the more trust you have established with the team, much less inappropriate will the questions seem. 

The curious case of the Product Owner & a Sprint Retrospective:

I have seen that in many cases, there is a general assumption that it is optional for the Product Owner to be present or not for the Sprint Retrospective and it is just the development team and scrum master who will discuss the sprint experiences. Let’s make one thing very clear. A Retrospective is an event for the Scrum Team, not just the Development Team. The PO is a member of the Scrum Team and plays a significant role in the sprint, therefore there are certain things the PO can inspect and adapt that will help the implementation of Scrum.

In most normal situations, Product owners are full, first-class team members. It is very critical for them to participate in retrospectives and they are as open as everyone else to hearing things they can do to improve. However, one can provide an odd case example of a product owner being an impediment to the team and preventing a frank and honest retrospective - by preventing the members speak / always expressing their opinions at the detriment to quieter team members.

 I would guess that what is really happening is that the team doesn't want any managers in the retrospective and the PO is playing the role of PO and manager. As such, trust is low and people don't feel comfortable having the manager there. In such a scenario, it’s the Scrum Master's responsibility to remove the PO until he/she has been able to coach the Product Owner into an understanding of the impact of their behavior.

If you're still tempted to run a sprint retrospective without your Product Owner, I would strongly suggest you to think as to WHY?

Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below and I’ll be more than happy to add them to my ‘Blog Backlog’.

Hope to see you soon, with more such interesting topics ☺

Kickstart your Agile Career. Enroll for a course now!