Product Owners: Understanding who the real MVP is – Part Two

Part 2

This is the second of a two-part series on product owners, what they do, how they do it, and why they’re so often vital to the success of development.
—

Product owners have a huge number of responsibilities within their remit. While Part One detailed the context of a product owner’s duties and responsibilities with stakeholders, development teams, user stories and product backlogs, Part Two here will detail about intelligent prioritization, managing feedback, juggling multiple expectations and expectation management.

Intelligent Prioritization

Product owners will judge user stories based on their size and perceived value in order to prioritize the backlog as intelligently as possible. If two user stories are roughly the same size but one has more value then naturally the more valuable user story will take precedence in the pecking order. This applies to stories with similar value but one is smaller. The smaller one goes first.

How do product owners know the value and size of a user story? Short answer is that they don’t. It’s educated guesswork based on constant communication with stakeholders to find out what is valuable, and the development team may help estimate what is big and small in terms of buildout and implementation. In the end most guesses are relative to the current project, but the time it takes to get these right is time well spent.

The Feedback Loop

An efficient agile team needs to deliver early and often to maintain velocity. It can accomplish this by breaking down user stories into pieces. In an ideal scenario the most clearly defined stories are at the front of the product backlog, while the more nebulous ideas are at the back. These will eventually be rendered clear and into bitesize pieces in a process known as backlog grooming.

Image via agile-scrum.be

Backlog grooming usually involves the entire team in addition to a few stakeholders. In general, these meetings focus on dividing user stories, acceptance criteria, and estimations. It’s important that these take place because regular communication is what typically binds the agile process together. As the Agile Manifesto says, “Individuals and interactions over processes and tools.”

Juggling Multiple Projects

When a product is finished, the work doesn’t just cease. Unless an app, platform, or service is completely shut down, development teams rarely have nothing left to do. When handing over projects to others, they’ll need to review responsibilities and make sure processes are well documented. In other cases, they may hang on to provide maintenance and upkeep themselves.

For product owners, this means they’ll have to start coordinating on other projects while all the above takes place. This means they must also begin prioritizing work across multiple products with new stakeholders. Unfortunately for them, this means the product backlog might now contain user stories for multiple projects.

Extreme Expectation Management

As the project progresses, stakeholders and clients may ask when their product or feature is being built. In cases where the development team has no scrum master, then dealing with these timelines and expectations falls to the responsibility of the product owner. No matter who it is, somebody must manage these expectations of the clients and stakeholders. Product owners forecast progress using story burndown charts, which show the cumulative number of stories been delivered over time and allow them to accurately forecast output, or timings of deliverables.

Image via: Scrum Alliance

If a development team’s output is difficult to predict, then there will be greater disparity between the optimistic and pessimistic projections. The gap separating pessimism from optimism is known as the cone of uncertainty.
However, with burndown charts, a product owner is able to answer a stakeholder’s question of “How much of the product will be complete by June?” with a fairly accurate estimation of the minimum and maximum number of completed stories.

The Bottom Line

Without a dedicated product owner, any development cycle is at risk of spiraling into a chaotic mess of unprioritized, unbuilt features, an unorganized backlog, missed market-windows, unhappy stakeholders and an overworked development team. Product owners bring order and maintain communication for the agile development process, and their contribution to the final outcome of a digital product is immense. The responsibility is gigantic, and that makes product owners the real MVP.