By Nick Butler
Tags: Agile
As Product Owner on a Scrum project, you’re the bridge between the business and the builders. Your job is to make sure both stakeholders and Scrum Team get what they need to succeed. Learn how you can team up with stakeholders in Scrum to help your Scrum Team deliver maximum value.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
Part of our ongoing Scrum primer series, this post shows you how to:
It’ll be followed by a post on one specific and important way you work with stakeholders: making sure you’re building what your customers need, a.k.a. product discovery.
In Scrum, a stakeholder is anyone with a vested interest in the product who is not part of the Scrum Team.
As Product Owner, you can think of stakeholders as anyone with an interest in or an influence on the product. These are the people who’ll help you discover, develop, release, support and promote the product. They include:
If Agile and Scrum are not well understood in your organisation, make sure all stakeholders understand why you’re working that way and what’s in it for them. Let them know:
Our What is Scrum guide may help with this. And, if you need to counter the common misconception that Agile is riskier than traditional project management, check out our guide to Project risk management with Agile.
We can also do an Executive Briefing to bring your leadership team up to speed with the benefits and mechanics of Agile. Contact Sean on +64 4 939 0062 or [email protected] to learn more.
Getting key stakeholders involved in the discovery process gives them direct experience of the process and input into the product.
Jess Limbrick is Project and Partnerships Manager at Life Education Trust, a charity working to empower and educate Kiwi children to make healthy choices. She’s been Product Owner for a number of Scrum projects. For Jess, a key stakeholder is the Trust’s CEO John O’Connell. John was heavily involved in the discovery phase of the Trust’s first Agile project. This meant he had clear expectations of what the work would be and how it would run.
“Through his involvement at that first stage, it’s easy to explain things because he understands how it all works,” Jess says.
In our next post we’ll show how to use a discovery process to set expectations for the product.
There are lots of ways to measure success. Success sliders are a good way of getting agreement on conflicting goals (time, budget, scope, quality etc).
Getting this agreement helps guide the discovery process by defining your priorities.
In Scrum you learn by getting solutions in front of your customers. Sometimes these solutions won’t give customers what they need. Let your stakeholders know that these failures are not only expected, they are beneficial. Each failure can be a win, because of the knowledge you gain.
As well as clarifying these expectations above, you’ll also want to clarify 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.
In our experience, the key difference between successful and unsuccessful Scrum projects comes down to how empowered the Product Owner is.
With empowerment comes:
The more time you have to devote to the Scrum team, authority you have to make quick decisions, and ability you have to drive the Vision, the more successful the project is likely to be. You can learn more about how an empowered Product Owner can power up the developers in the Scrum Team here. We’ll look in more detail about how you develop the Vision in the next post on product discovery.
“I know definitely that if I can put in a little bit more time into the project, we get a better outcome,” says Jess Limbrick.
At the Trust they try to limit Jess’s non-project workload for the duration of the project.
“We look at what other things coming up that I can either delay slightly or hand off,” she says.
Jess is lucky because the collegial atmosphere of the Trust means this hasn’t been a problem.
“We all pitch in. We’re used to pitching in I guess,” she laughs. “Classic charity scenario.”
Because Scrum relies on the power of self-organising teams, it works best when the Product Owner is also self-directed rather than being a conduit for — and waiting on — decisions made by others.
You can see this as a spectrum: Scribe > Proxy > Business representative > Sponsor > Entrepreneur. The further along the list you sit the more empowered you are to drive the product, and the more successful the product is likely to be.
Because the extra cost to an organisation of having an empowered Product Owner tends to be small relative to the overall cost of a project, and the benefits tend to be large, it makes sound financial sense.
While it’s vital for a Product Owner to be decisive, even if you’ve been empowered it’s not always easy. You’ll often have many stakeholders who have even more ideas about your product. If you don’t listen you’ll miss opportunities and lose buy-in. If you listen to everyone you’ll end up with a product that tries to be all things to all people and so satisfies no-one.
To help manage this tension:
Here are some ways to think about the different types of stakeholders in Scrum.
Customers are your most important stakeholder. They’re almost a category in their own right. Without customers there’s no product. The key way you work with customers is by finding out what they need. As mentioned, we’ll look at this in more detail in our next post on product discovery.
Within your organisation there are a number of people who understand what makes your customers tick. Customer support, contact centres, front of house and sales staff talk to customers daily and develop a good understanding of their needs and pain points. Your marketing, user research and analytics experts dig into customer behaviour and motivations.
These people tend to have a vested interest in your product. They’ll be supporting or selling the product so will want to understand it well, and be confident it delivers what your customers need. The same goes for people who support internal products or systems. This means that customer proxies are valuable allies.
Product ownership specialist Roman Pichler recommends breaking down stakeholders by interest and power, using the grid set out by Colin Eden and Fran Ackermann in their book Making Strategy.
Place your stakeholders (or groups of stakeholders) on this grid, with high interest high power stakeholders top right, low interest low power examples bottom left and so on.
You can then base how you work with each group by their place on the grid.
Treat the high interest, high power Players as your partners, and collaborate closely with them. Try to get them along to your discovery sessions to understand your product and also to Sprint Reviews to see the progress.
Because knowledge is power, you can think of the customer proxies as Players.
Low interest but high power Context Setters influence the environment in which your work takes place. This might include things like its priority, visibility or how it’s resourced. Their power makes it a priority to spend time with them, listening to their views and keeping them informed. Focus on how the project impacts (and ideally benefits) their area of influence, not on the nitty gritty details.
Subjects have high interest but low power. Often their interest comes from being affected by the product. This makes them keen to influence so give them opportunities to provide feedback, such as getting them along to Sprint Reviews.
As the Crowd have low interest and low power, the amount of time you invest in them can also be low. Keep them informed through regular updates via whatever broad-reach communication tool your organisation prefers.
You can help out your stakeholders in Scrum by highlighting what’s coming up for them and the product.
The more time you’re going to want from people, the more warning they’ll need. And the further you get into the project, the more detail you’ll be able to give them.
As Product Owner, you’ll often want stakeholders to give you input into the Backlog (though the final decisions are yours). It helps to book in time to gather this input before you have your Sprint Planning and Refinement meetings with the Scrum Team.
“Where things cross over with other people’s work, I try to make sure that we were a couple of steps ahead of what the Scrum team was going to need,” says Jess.
The one Scrum Event that stakeholders can attend is the Sprint Review. This is their chance to follow the progress and provide feedback. It’s also your chance to demonstrate the value you’re delivering (not just features you’ve built but the outcomes you’re achieving). Since people, especially Players, tend to be busy it helps to get the Review in their calendars well in advance.
To make it easier to communicate your future plans for the product to your stakeholders and Scrum Team it helps to map out your plan.
Focusing your Roadmap on the goals each step in your plan aims to achieve makes it easier to show stakeholders the benefits of investing time and money. It also gives your Scrum Team motivation for each stage and an opportunity to think ahead.
Product Roadmap template from Roman Pichler
Jess has been Product Owner for a number of different products and projects. This means she may not be the owner of a system being worked on before the project starts. She works with that owner in the discovery process and can bring them along to Sprint Reviews to get feedback. Working closely with them means that it’s easy to hand back the system once the project is over.
As each phase of work has been completed successfully, it’s easier to get the time to devote to the Scrum Team, time from stakeholders, and authority to make decisions.
“I think the success of the past makes it a lot easier as you continue.”
A new project that the Trust is working on has external stakeholders in the form of corporate donors. While on a day-to-day basis they have low interest and low power, they have high interest in the results of their support and their donations are vital for delivering the product.
“Our corporate dollar obviously sits in a totally different space because they’re very much interested in what you’re doing, in how they can tell the story of how they’re helping,” Jess says.
“We already have a quarterly update process where we keep them in the loop with how things are progressing,” she says. “After that we’ll probably do something with the kids, getting them in front of a camera and letting them talk about what they’ve learned.”
Having an inspiring Vision for your work also helps get donors on board initially.
Because they are very interested in seeing the value their dollar is delivering it can be worth inviting donors along to Sprint Reviews.
Much of the work of the Product Owner is about building buy-in with the project. The great thing is that Scrum and Agile help with this.
Because you focus on regularly delivering working solutions you can regularly demonstrate the value of the product and project. Every Sprint you have a Review in which you can not just tell stakeholders what you’ve achieved, you can show them.
The Scrum pillar of Transparency means you display your progress via physical and digital Scrum boards for all to see.
Scrum favours face-to-face communication. This helps you answer questions and tease out implications in real time rather than in dribs and drabs through things like email or reports.
In your discovery work you focus on outcomes not features, helping you come up with an inspiring Vision that motivates the organisation. Discovery artifacts such as your Pragmatic Personas, Press Release and Elevator Pitch are powerful communication tools. Having key metrics focuses priorities and lets stakeholders track progress at a glance.
In our next post, we’ll detail how to do this discovery work.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
In New Zealand and keen to get to grips with Scrum and the Agile mindset? Check out our Agile training:
Agile Professional Foundation certification, Wellington, NZ – two-day ICAgile course
Introduction to Agile methodology, Wellington, NZ – free two-hour workshop
Agile Accelerator team assessment – Agile review and action plan
User stories and stakeholders – bringing people on board with Agile — Boost blog
The GO Product Roadmap — Roman Pichler
