As a Scrum Product Owner, you get to make the world a better place, one customer at a time.
That’s because Scrum is designed to help Product Owners succeed. The goal of the Scrum Product Owner and the goal of the Scrum framework are one and the same: maximising the value delivered to the customer.
This guide shows you how Scrum is set up, and how you can make best use of this set-up to build a product your customers love.
You’ll learn how to:
consistently deliver valuable working solutions to your customers
work successfully with your Scrum Team and your stakeholders
discover the product your customers are waiting for
manage your Product Backlog for maximum value and minimum effort
constantly improve your product and processes.
We’ve pulled everything we know about succeeding as a Product Owner into one comprehensive PDF download.
"A great resource ... extremely thorough!"
— Jess Limbrick, Product Owner, Life Education
Scrum is one of a number of Agile frameworks. Agile is a philosophy, a set of values and principles, that guide the way you work. Until the Agile mindset becomes second nature, Scrum gives you a clear structure and process to follow, as defined by the Scrum Guide. This makes it a great way to start your Agile journey.
Scrum works on the principle that decisions are better based on what you know than on guesswork.
In Scrum you develop working solutions in regular, short iterations, working collaboratively and transparently in self-organising and self-contained teams, and inspecting and adapting as you go.
This allows you to you sustainably deliver maximum value. Delivering working solutions in short iterations lets you test your product with your customers and make changes based on what you learn. It also gives you regular chances to review and improve your processes. Combined with self-organising and self-contained teams, and a collaborative and transparent approach, this means that the right people can make decisions based on the right information at the right time.
A Scrum Team is made up of the Product Owner, the Scrum Master and the Development Team.
Here’s how product ownership expert Jeff Patton sums up the aims of each role:
Product Owner: Build the right product
Development Team: Build the product right
The Product Owner is an integral part of the Scrum Team. You use your understanding of customer needs and organisational goals to create a vision and a strategy for your product, which you communicate via the Product Backlog. You point the team in the right direction, they show you how to get there, and you work together throughout the journey.
To do this you need to be:
available and responsive
decisive, especially around prioritisation
empowered with the time and authority to make decisions.
While being a Product Owner is a collaborative process, the Scrum Guide states that the Product Owner is one person. However, occasionally it may be preferable to have multiple Product Owners. This case study shows how you can make multiple Product Owners work in Scrum.
And here are some more tips on great product ownership.
The Development Team build your product. If you’re creating software, they’re the coders, designers, testers and so on. If not, they’re creating whatever product (or service) you offer. They build what you need in order to deliver the outcomes you’ve specified in the items in your Backlog.
The team is cross-functional and self-organising. Because they have all the skills they need to do the work, you avoid delays caused by handover. And, if each team member is also cross-functional, you avoid specialists becoming bottlenecks. As Product Owner, you don’t assign tasks to individual team members and only they decide what is achievable each Sprint, and how it is achieved.
The Scrum Master shows the whole Scrum Team how to do Scrum. They make sure that the team is working well together, that they are following the Scrum framework, and that nothing is blocking their work.
Scrum has three artifacts that are used to track your work in a way that ensures everyone can see and understand what’s involved. These are the:
Product Backlog
Sprint Backlog
Increment
The Product Backlog is a prioritised list of everything that is known to be needed in the product. It does not prescribe product features, but rather it describes outcomes — the benefits the product will deliver.
As Scrum Product Owner you decide what goes in, and what the priorities are. You get input from stakeholders and the rest of the Scrum Team, but the buck stops with you.
One of the ways you get input is in backlog refinement (a.k.a. grooming). This is an ongoing process of prioritising, fleshing out, and estimating the size of items in the backlog. At Boost we tend to schedule in a refinement meeting towards the end of the current Sprint.
Before the refinement meeting, the Product Owner gets the stories at the top of the backlog in priority order and adds enough detail to start a discussion with the development team about what’s involved.
During the refinement meeting the Development Team clarify each story, discuss how they would complete it and estimate its size.
In Scrum, the iterations are called Sprints. The Sprint Backlog is the team’s trackable to-do list for the current iteration. It’s selected from the Product Backlog, and discussed so everyone knows what needs to be done to deliver the next artifact, the Increment.
It’s often tracked both electronically and via a big visible information radiator: a Scrum board that lets you see the status of each item in the Sprint Backlog at a glance.
The Increment is the next step towards achieving your vision as Scrum Product Owner. It’s what you get when you add the results of the current iteration to the product created by all the previous Sprints.
The Increment needs to be “Done”, it needs to give you as Product Owner a working solution that you could test with users (even if you’re not going to release it into the wild).
Sprints are regular iterations of no more than a month. Each Sprint has a cycle of meetings in which the Scrum Team plan, monitor and improve both product and processes.
The whole Scrum Team plans the work for the next Sprint. The Development Team runs through items from the Product Backlog in priority order, estimating the amount of work involved and choosing those they forecast they can complete. The more you’ve done in refinement, the more time the team have to work out how they’ll do it.
As Product Owner you’ll clarify the items with the team, and together you’ll discuss what needs to be done to complete each item, deliver a working solution and achieve an overall Sprint Goal.
The Development Team coordinate the upcoming day’s work at the Daily Scrum. To keep it short (under 15 minutes) many teams stand up for the meeting (hence the other name, the daily standup).
A Scrum board is a good prompt for the discussion, as is answering — in a conversational way — three questions:
What did I do yesterday that helped us meet the Sprint Goal?
What will I do today to help us meet the Sprint Goal?
Do I see anything that blocks me or the team from meeting the Sprint Goal?
For the Scrum Product Owner, the Sprint Review is your chance to put the latest Increment of your product through its paces. You get to show off your progress to everyone with an interest — stakeholders, subject matter experts or actual customers — and learn from their feedback.
The Review starts with a working demo of the features created in the Sprint. This is your chance to demonstrate the value you’re delivering. Explain how these features benefit your customers and the business. This both builds buy-in and gives the Development team deserved recognition for their work.
Based on feedback from the Review, and what you learn from getting the new Increment in front of your customers, you can tweak the items and priorities in the Product Backlog.
Where the Sprint Review looks at your Product, the Retrospective looks at your processes. The Retrospective is also introspective. The Scrum Team inspects itself and identifies ways it can improve.
To ensure the improvements happen, make them actionable, set a timeframe and give someone responsibility for ensuring everyone does what’s required to complete the action.
The Retrospective is a chance for the Scrum Product Owner to lead by example and demonstrate the Values of Scrum: commitment, courage, focus, openness and respect.
In Scrum you’re more collaborator than client.
Ideally you’ll be colocated with the rest of the Scrum Team. This means you can make use of the most powerful communication tool available: face-to-face discussion. If you can’t hang out with them all the time, do it often, either in person or via video conferencing.
Developers work most effectively when a Product Owner knows the product well, and communicates this knowledge responsively and decisively.
By know the product we mean knowing what the users want from it and how they'll use it, now and in the future. You gather this intelligence through product discovery.
The Scrum Product Owner doesn’t need to be a technical expert to communicate with developers, but does need to understand their technical lingo and concepts.
You need to be able to listen and to ask questions until you understand. Repeating an explanation in your own words can help clarify that you’ve nailed it.
When giving feedback, make it clear and specific. If a feature is working brilliantly, for example, let them know the ways it’s making the customers’ lives better.
For ongoing projects or value streams, you’ll want a flexible, high-level plan for the future, a product roadmap. This gives the team the chance to think ahead.
This is sometimes called being available. Developers often have questions or need to get work checked and, hopefully, accepted. The faster you respond, the less downtime there is, raising productivity.
Probably the most important decisions you’ll make will be about priorities.
You need to be ruthless in pursuing the top priorities first.
You need to know what the Minimum Viable Product is and not push for a full-feature, big-bang release because that means you get none of the benefits of the iterative nature of Scrum.
Learn more about how a product owner works best with developers.
Because the Scrum Master is the expert on Scrum best practice, you’ll want to leverage this expertise.
They can advise and assist you in any aspect of the Scrum Product Owner role, including sharing your vision, managing the backlog and running events.
They’re also a useful ally in dealing with stakeholders and others outside the Scrum.
Demonstrating the Scrum Values in these ways helps you get the most from Scrum and your Scrum Team.
Commit to the Scrum. Make sure your other work doesn’t keep you from being available and responsive when your team have questions or items they’ve completed they want you to check.
Stick up for your team when they come under external pressure to break from the Scrum framework by, for example, working on other projects. And stick up for your customers if the Development team aren’t keeping them top of mind.
Relentlessly focus on prioritising only the work that will achieve your vision. Keep the Backlog in priority order with the top items well understood, and keep conveying your vision with energy and enthusiasm. A passionate Product Owner is powerful motivator.
Be open to feedback and ideas. With their in-depth understanding of the inner workings of the product, your Development Team often spot ways it can be improved that will deliver long-term value, such as by clearing technical debt. And be up-front in your communication with the team. Being open builds trust, which is crucial for a successful Scrum Team.
By respecting the Development Team’s expertise, you get the right people making the right decisions. So you want to:
describe outcomes — not features — in your backlog items
accept their estimates of the work involved in each backlog item
avoid pressuring them to bring more items into the Sprint.
The three pillars of Scrum are transparency, inspection and adaptation.
The Scrum Product Owner maintains transparency by keeping the team’s work both clear and visible.
You keep things clear by building a shared understanding of the work and its progress through face-to-face discussions in your Scrum meetings. You can also collaboratively come up with agreed ways of working such as a Definition of Done and a Team Charter.
You keep things visible by making sure artifacts like the Product and Sprint Backlogs easy-to-see and up-to-date. Even if you track the Sprint Backlog through a digital tool, it’s worth having a big, visible Scrum board too.
Make the most of the opportunities to check up on your product and processes that are built into Scrum. Get involved at the Retrospective and, especially, prepare for the Review by inviting stakeholders and reminding yourself of the outcomes you’ve delivered.
You only get the benefit from inspection if it’s followed by adaptation based on what you learn.
So you’ll want to take on board any feedback you get in your retros and reviews. Take what you learn when you test your new Increment with your customers, and update your Product Backlog accordingly.
To test your new Increment, each Sprint you need to deliver a working solution.
Having a Definition of Done means you can define what a working solution is. You can spell out that an item is Done when it’s been through things like code review, testing and integration.
If you release your Increment, you deliver value to your customers and you gain value from what you learn about their use of your product. If you don’t release it, you can still get value from, for example, beta testing.
The Scrum Product Owner brings together the business and the builders of the product. You make sure both stakeholders and Scrum Team get what they need to succeed.
You make sure your stakeholders know what to expect from your product and process, and also know what you and your Scrum team need to work effectively.
A stakeholder is anyone outside the Scrum Team with an interest in or an influence on the product — the people who’ll help you discover, develop, release, support and promote it. They include:
customers
project sponsors
key decision-makers
everyone needed to deliver the product
colleagues who support and understand your customers
people who need to sign off on new content or features (such as comms or legal)
external parties such as donors or regulators.
If stakeholders don’t know Scrum well, let them know how and why it works as it does. Our What is Scrum? blog post can help with this, as can explaining how you’ll use Agile project risk management techniques. Explain that Scrum is an iterative process, where your understanding of exactly what needs to be delivered grows with each Increment.
Let your stakeholders know:
how and what you’ll communicate
what the deliverables and artifacts will be
what meetings or events they might attend
the time you’ll want from them.
Once the project is up and running, you’ll often need stakeholders’ input into the Product Backlog, so book in time to get this input before your Sprint Planning and Refinement meetings with the Scrum Team.
And book them in for the Reviews, so they can follow progress and provide feedback.
You’ll want to get agreement from stakeholders on what success looks like. One useful way of doing this is by running a Success Sliders exercise. This lets you jointly decide the relative priorities of conflicting measures of project success (time, budget, scope, quality etc).
To communicate your plans for the product to both your stakeholders and Scrum Team you can map out a high-level plan, or Product roadmap.
Involving stakeholders in your discovery work keeps them in touch with your evolving understanding of the product and its users.
Let stakeholders know what you’ll need for the project to be as successful as possible.
This includes things like a space for a colocated Scrum Team, tools such as physical whiteboards and digital Agile project management software, along with your communication tools. Plus piles of Post-it pads and stacks of Sharpies.
Last but in no way least, as Scrum Product Owner, you need to be empowered.
In our experience, the more empowered the Product Owner is, the more successful the project.
When you’re empowered you have the time and authority to develop and deliver the vision.
Scrum relies on the power of self-organising teams. This means the Scrum Product Owner will be most effective when self-directed, rather than channeling — and waiting on — the decisions of others.
The best way for Scrum Product Owner to get this empowerment is to demonstrate the value the product is delivering. Watching happy customers use your latest Increment really brings home to the powers-that-be the positive impact your Scrum is having.
Get the tools, templates and tips you need for a successful discovery workshop.
"Brilliantly done - very impressive."
— Jimmy Ling, Agile Delivery Lead, NA
If you’re based in New Zealand, Boost can plan and facilitate your discovery workshop for you. Contact us to learn more. It’s a great way to get clear what you want to achieve, how long this will take and how much it will cost.
Learn how the project discovery experts can take the hassle out of building your business case and getting your project up and running.
The product vision explains why you’re building the product, and how it will make the world a better place. It’s both goal and prompt, and helps get stakeholders and the Scrum Team behind the product.
Your strategy is the way you’ll achieve your vision by giving a set of customers something they need, and can’t get elsewhere. It defines your:
vision
target customer
point of difference in the market.
To measure how your product strategy is working, choose your key metrics. Setting ambitious targets helps you maximise the value you create.
Often there are a number of ways you can execute your strategy. Prototyping lets you test that the assumptions in your strategy about your customers and your product are correct, and do this without the cost of building the full product.
You want to:
understand your customers
get clear about the problem you’re solving
come up with a range of solutions
prototype and test these solutions
repeat.
You can do some or all of this before your first Sprint or in your early Sprints.
The Google Design Sprint is a tried-and-tested, five-day prototyping process. It’s different to the Scrum Sprint but has the same Agile roots.
Even if you’re not using a Google Sprint, you can pick up handy tips for prototyping in our day-by-day Google Sprint guide.
To learn what makes your customers tick, and create personas that capture this, check out your:
existing customer research
user statistics, analytics and search logs
common call centre or helpdesk questions
You can back this up by running:
surveys
focus groups
usability testing on an existing or competitor’s product
customer interviews.
Combining usability testing and interviews lets you put people at ease and dig into their needs and experiences in a conversational way, which often gives great insights. To learn more, read Steve Krug’s usability testing bible Rocket Surgery Made Easy.
Define the people your solution will help and the problem you’ll solve for them. Note down the assumptions you’ve made in defining this problem so you can test them later.
Consider multiple solutions to solve your customers’ problems. Your first solution may not be the best. Once you have a set of solutions, pick the best for prototyping.
Create the simplest prototypes possible — so you haven’t wasted effort if your solution fails. Test the assumptions most likely to derail your solutions. What are the biggest risks?
You, the Scrum Team and your discovery stakeholders should watch the tests together. That way everyone has the same understanding of which solution works best.
To get to the point you can start building your product, you need to map out how your customers will use it, and prioritise the smallest set of features needed to make this experience worthwhile: your Minimum Viable Product.
Once it’s built, usability test your product, check your analytics and bug reports, talk to your customer service people, and provide your customers a way they can give you feedback.
Keep tabs on your key metrics. Have you hit your stretch targets? If not, what might you do in upcoming Sprints to get there?
Then continue this process with each new Increment.
The Scrum Product Owner owns the Product Backlog. It’s your hands-on tool for guiding what gets built.
The Scrum Guide defines the Product Backlog as “an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”
The Product Backlog is:
ordered with the highest priority items at the top
less detailed as you go down
always changing.
As Product Owner, you decide what items go in, and where they sit in the priority order. You do this with the help of your discovery stakeholders and the Development Team but the buck stops with you.
The items in your Backlog start as a user need identified in product discovery. Often this will just be a stub — a brief, meaningful label.
The Scrum Guide doesn’t mention user stories. The individual items in the Product Backlog could be things like requirements, use cases, specifications, bug fixes, maintenance tasks or user stories.
At Boost we usually go for user stories, so that’s what we cover here. The details may change if your Product Backlog items are not stories, but the basic principles are the same.
A user story in Scrum is an evolving description of something your customer will do using your product. It is based on a short statement of the customer benefit, written from the customer’s point of view, in the customer’s language. The story gets more detail as a result of conversations the Product Owner and the Development Team have to build a shared understanding of what the story involves.
Following the INVEST formula, user stories should be:
Independent
Negotiable
Valuable
Estimable
Small
A user story doesn’t start with all the elements below, they get added as you go.
When the story is done, the Development Team will let you know the story is ready for you to check if it meets the acceptance criteria. The sooner you can do this, the better. If there are change the developers need to make, they’ll find this easier if it’s not been long since they were working on it.
Once it’s accepted, you’re another step closer to your Sprint goal and delivering more value to your customers.
We’ve pulled everything we know about succeeding as a Product Owner into one comprehensive PDF download.
"A great resource ... extremely thorough!"— Jess Limbrick, Product Owner, Life Education
Make a bigger impact tomorrow
