Willem Vermaak
& Robbin Schuurman

Number 10 of the Principles behind the Agile Manifesto is a key phrase for any Product Owner working with Scrum:

Simplicity—the art of maximizing the amount of work not done—is essential.

Over the years, we’ve seen many cramped Product Backlogs, endless walls of stickies, and roadmaps containing years’ worth of ideas. The many Product Owners we meet understand the problem. They all nod in agreement: “Yes, I should have more focus” (there is a reason it’s a Scrum Value!), “and I should keep Product Backlog in a manageable state.” So how come most Product Owners let the Product Backlog become this huge list of user stories?

In a majority of cases, it seems they just can’t say no, or their stakeholders don’t take no for an answer. For every request, there seems to be some reason to say yes, add it to the Product Backlog, and increase the amount of work to be done.

We want to help Product Owners start mastering the art of saying no.

We start by asking Product Owners the following questions: can you explain what type of stakeholders you have? Which ones are very important to you, and which ones should you interact with less? Because, in the end, not every stakeholder is equally important, and Product Owners should not feel obligated to spend the same amount of time with every single one. A way to visualize this is to divide stakeholders into four groups:

• Stakeholders you merely need to monitor (the minimal effort of sharing information in intervals keeps them at a distance).

• Stakeholders you need to keep informed (proactively planning something or sending them information keeps them at a distance).

• Stakeholders you need to keep satisfied (sending them only information that’s relevant to them).

• Stakeholders you need to manage closely. It goes without saying that the bigger this group, the busier you are, so you want to limit the number of people in this group to a minimum (interacting with them frequently).

Next, create a communication strategy for each group (who they are, what their objectives are, the type of messages you’ll send them, and channels you’ll use to send them). Make sure you understand their context and background so you can provide answers relevant to their perspective. For example, give the IT manager an IT answer.

As Product Owners start practicing saying no to their identified and grouped stakeholders, they should keep the following considerations in their minds:

1. Who is asking the question? What type of stakeholder are they?

2. What is the actual question? Do I truly understand what is being asked and why?

3. Intention. Am I going to say yes, no, or maybe (where the latter effectively is also no, but might not be perceived as such)?

4. Say no in a way that relates to the question and/or stakeholder.

5. Listen carefully to whether the stakeholder understood and accepted the no. Is additional information needed? If a discussion starts, decide whether this is the right time to have that discussion. Sprint Reviews are often great opportunities for open discussions.

Act according to the Agile Manifesto and the Scrum Values. Stay focused on your vision and have the courage to say no, but be transparent to your stakeholders about your why. Start maximizing the work not done by saying no!