[2025] Advanced Agile Product Owner Masterclass

I wish every team knew what it was like to have a great product vision.
And even more importantly, how to use it daily when developing the product.
Check out my course, Agile Product Owner Role, to learn more about product vision and why it's important.
 

Once you have a clearly articulated vision that the team understands, we need to get to a backlog.
This is part of the agile process that doesn't have much guidance for teams in many of the agile methodologies, but it's an important part of making sure what is built aligns with the vision and is valuable.
A Road Map defines the key features and characteristics to achieve the product vision, and in what order.
 

When done well each release has something valuable and exciting to offer users.
So how do we plan releases to make this happen? Well first we need to look at the needed inputs to release planning.
We start with the product vision and strategy, the roadmap, and high-level epics and user stories for our release features.
 
 

Back refinement is an ongoing and critical task for product owners.
It's an essential input to so many parts of keeping the team running at a good cadence.
Let's look in more detail at how to run a backlog refinement meeting.
 
 

Breaking down features in agile is important to the team being able to work quickly.
It's about keeping the flow of work moving and the dialog focused.
High-level software engineers and architects love features, and the sky is the limit.
 
 

A persona is a way to represent a user role by characterizing them as a specific person that we can empathize with.
Personas help teams focus and discuss how various user goals look different when using the insight from each persona's point of view.
Personas build empathy and help the team focus on a few typical archetypes of users, rather than trying to please thousands.
 
 

User stories are a common technique to help teams understand precisely what they're building.
User stories provide a placeholder for conversation and continued dialogue about a specific piece of functionality from a user perspective.
To provide some context as we look at what good user stories look like, let's look at one from our GoHealth app example.
 

A user's story map is a powerful visual that helps the entire team see the forest though the trees.
By organizing user stories in a visual format.
A story map is all about telling the whole story versus a small part of it.

Story slicing or splitting is an essential skill, and can prevent many of the typical challenges agile teams experience.
The features on the roadmap are bundles of functionality that the team typically takes many sprints to create.
To build these features effectively and get the value delivered in increments, the functionality needs to be broken down further into user stories.
 
 

So how do we know the user story will meet all of the users expectations? Teams define this with acceptance criteria, which are the conditions that tell us when the user story is working as intended and satisfying the customer.
Although the team may define it altogether, the product owner plays the main role in deciding on this acceptance criteria.
These conditions are typically created and owned by the product owner and are attached to the user story.
 

A common technique to get the team engaged and working on the product is to hold a user story workshop.
It's a hands-on meeting where the team brainstorms and writes user stories for the solution or product being worked on.
The product owner may work with a scrum master or a team lead to plan the workshop.
 

The product owner has a critical role in prioritizing the backlog.
It's about taking all of the features and items submitted and under consideration, and finding their place in the backlog.
When using a funnel-shaped backlog, this is a much easier task than a stacked backlog.
 
 

Effective teams and product owners know what their number one and number two priorities are, along with three, four, and five.
Their items are ranked.
I don't advocate for ranking all of the items in a backlog, but for sure the top 10 priorities in the near future, and top 10 conceptual items that are further out.
 

Grouping By Categorization
Creating a hierarchical grouping of items helps many teams make decisions and stay focused.
For some teams, features and items need to be categorized before forced ranking, or even categorized into priorities to see how alignment is working with the roadmap, vision, and strategy.
Categorization as a prioritization technique involves getting the team together to create a shared understanding and common dialog about priorities.
 

It feels good to vote on something and have your say, right? Well, applying this to requirements prioritization is a fun and engaging way to get feedback on the priorities from the team or a group of stakeholders and users.
Voting does not mean that a decision is necessarily made, but rather it's a facilitation technique to get dialogue going and see where a group stands on its priorities.
When I do a voting meeting, I prepare the items to vote on.

Many agile teams use a Definition of Ready to help with the planning process.
It's an underutilized tool that can bring powerful results to the team.
It helps the team with an agreement on expectations of what makes the team successful when bringing in an item or story to a sprint and it prevents re-work.
 

Definition of done is a tool teams use to agree on what done means and how the team will measure if a user story or backlog item is fully completed.
This tool can also be applied to other things like a release, a minimum viable product and the product itself.
Having a definition of done helps teams to find their tasks, estimate, develop accountability and set expectations.
 

What happens when teams work fast and furious without an eye towards the product vision and road map, and they take shortcuts, rather than doing it right the first time? Well, they typically create a lot of rework and pain, and in Agile, it's no different.
Technical debt is the cost incurred for cutting corners in the short term, and Agile teams can create more than an appropriate amount of it, when only focused on the current sprint.
When too much technical debt happens on a solution, over time, the team's pace and velocity slows down.
 

The product owner role is key to keeping the team on track.
And this means being an active and regular participant in the cadence of agile meetings or ceremonies as some teams call them.
Depending on what flavor of agile your team is using, your team's ceremonies and what they're called may differ.

Estimating isn't just for developers on agile teams.
Everyone plays a role in the process, including the product owner.
The product owner has a large stake in the estimates, and one that might not be obvious.

Sprint planning is a ceremony in Agile that teams use to plan the upcoming sprint or iteration.
It's a collaborative effort involving the entire team.
A team leader facilitates the meeting, and a product owner clarifies precisely what will be built through user stories or product backlog items.
 

The Daily Standup is a quick, 15 minute, time box meeting, for the team to gather, and make sure their work is progressing.
There's a lot of flexibility in the standup ceremony, and also a few simple guidelines.
The first guideline, is that the product owner and the entire team, needs to be there.
 

A sprint review meeting is another Agile ceremony the team uses to keep the Agile values front and center.
This meeting focuses on Inspect and Adapt as a value of continuous improvement with the product being built.
At the end of each sprint, this meeting is held and the team shows what they've accomplished.
 

The Retrospective is a key meeting to improve how the team works, and it happens after each sprint.
It's about the team taking a brief pause together to reflect and improve how they create value, work together, and how they enable a good cadence of flow of work.
It's about continuously improving and getting better as a team, each sprint to build a better product.