Scrum Product Owner Roles and Responsibilities

Find me on: 
LinkedIn Twitter

Depending on how you look at it, the Product Owner on a Scrum team wields all the power… or next to none of it.

That’s because the Product Owner is the overall vision holder for the product but has no say in how that vision gets implemented. On a Scrum team, the Product Owner represents the interests of the business stakeholders. She prioritizes which work gets done and sets the criteria to identify when the work is considered ready for end-users. These responsibilities both come from the Product Owner’s primary contribution to the Scrum team: the product backlog.

The product backlog is the list of user stories representing all the features under consideration for the project. Because the Product Owner is the sole Scrum team member in charge of prioritizing the product backlog – determining which features are prioritized for the next production sprint – the Product Owner controls the direction of the project at any given point in time.

Agile Alliance defines the responsibilities of the Product Owner as:

  • Clearly identify and describe product backlog items
  • Make decisions regarding the priority of product backlog items
  • Determine whether a product backlog item was satisfactorily delivered
  • Ensure transparency into the upcoming work of the product development team
  • Decide when to release the product

In this article, I’ll look at each of those responsibilities and discuss their impact and importance to a Scrum team.

A Product Owner Describes the Product Backlog

The Product Owner is responsible for creating and maintaining the product backlog. Since the backlog is the project’s to-do list and contains all the user stories, you can see how important this is to a Scrum team.

How the user stories are portrayed in the backlog can make a huge difference in the team’s efficiency. The Product Owner must solicit all the right input from business stakeholders. Each feature must satisfy the requirements and needs of the business. Poorly described user stories can send the development team down the wrong path, wasting time and money.

The Product Owner needs to make sure that user stories are clearly written so that the development team understands exactly what’s being asked. They also need to be prepared to answer any questions during planning sessions, and to procure any answers they can’t provide themselves.

A Product Owner Prioritizes the Product Backlog

One of the most important roles in Scrum is the prioritization of the product backlog. This is done solely by the Product Owner, who considers a variety of business factors and influences when making those decisions. Sometimes business stakeholders have competing interests – it’s up to the Product Owner to weigh those interests and plan them out accordingly.

The beauty of Scrum is that the backlog is not prioritized just once, but after each and every production sprint. In many cases it’s prioritized almost continuously as business conditions change. This allows businesses to shift their focus and initiatives on a dime – or, at least, in as little as one week to a calendar month, depending upon the duration of each sprint.

Because prioritizing is an ongoing, evolutionary process, the Product Owner must be willing to give careful consideration to the order, and not simply “wave the next user stories through.” The more strategic thought a Product Owner puts into prioritizing, the more satisfied your business will be with the overall results.

A Product Owner Determines When a Feature is Done

How do you identify when a user story is done?

By its acceptance criteria, of course. And since the acceptance criteria is part of the user story, which is part of the product backlog, it comes under the domain of… you guessed it, the Product Owner.

The Product Owner works with business stakeholders to figure out what the acceptance criteria should be. These are a short set of reminders to the Scrum team about the desired behavior of the application once a story is completed.

The finer points are filled in through conversations between the Product Owner and the development team, and it’s not until the Product Owner reviews their work that the story is deemed “shippable.” This helps keep the process lean and fast. The Product Owner also acts as a liaison for business stakeholders and end-users, deciding whether each story meets their collective expectations.

A Product Owner Ensures the Transparency of Upcoming Work

The Product Owner must always look beyond the next sprint when prioritizing the backlog. While priorities can easily shift between any two sprints, the Product Owner must anticipate which user stories will be needed in the short-term.

That’s because many of the user stories need to be broken down into smaller pieces before they fit within a sprint. These larger stories, called epics, serve as placeholders for upcoming features. But once a feature is on the “hot list,” the development team needs to start thinking about it, breaking it down into story points and discussing how they’ll approach it.

So the Product Owner needs to not only maintain top priorities for the next sprint, but also maintain a small, rolling list of high priority user stories that are “ready-to-go.”

You can read more about the similarities and differences of epics and user stories, or view our free, in-depth webinar. Keeping a healthy mix of epics and sprint-ready user stories is one of the Product Owner’s biggest challenges, but it’s what gives transparency to the development team’s upcoming work.

A Product Owner Decides When to Release the Product

Because the Scrum team members work together to always ensure the product is shippable, that means it could be shipped at any time. In fact, one of the guidelines of Scrum is that the Product Owner can decide to ship the product in its current state at the conclusion of any sprint. The development team should then be able to put it into production over the course of one additional sprint, often called a “release sprint.”

The Product Owner, acting as the representative of all stakeholders, must understand and decide when the product includes enough business value that it should be put into users’ hands.

Ever hear of a software project shipping early? When using an older waterfall-based approach, that seldom happened. But with Scrum we see it all the time, because the Product Owner can decide to ship the product before all the originally envisioned features are completed. The only criteria is that it’s ready to deliver value – to at least some subset of end-users – now.

Help for Product Owners

Because the Product Owner role is where the business and the development team meet, it’s a critical juncture for any Scrum team. Prioritizing the product backlog is the most obvious facet of the Product Owner’s importance.

If your business and development team struggle to get on the same page, or your Product Owners need help maintaining an efficient product backlog, Ascendle’s Agile Coaching services might be just what you’re looking for. Contact us to see how Ascendle could impact your project team’s results today.

Comments