Scrum Teams Are Powerless Without Knowing When and How to Say No!

The more often Scrum teams say yes, the more distracted they become.

How often do you get the following questions?

• Can you add this small change to the current Sprint?
• Can you implement this feature next Sprint?
• I’ve found a bug. Can you check it?
• I’ve got an idea. Can we talk about it?

I imagine these questions are present in your daily work. It’s a simple choice between yes and no, but it can be overwhelming. 

Think about it for a minute. How often do you say yes? How does that impact the scrum team’s focus?

I used to be a yes person. Helping people motivates me. I was glad when someone asked for my help because I felt trusted and often said yes. I thought I was being friendly and helpful, but I was missing the point; I was pleasing people and distracting the team. That’s just our nature as humans. We enjoy helping others just as much as we enjoy receiving help. We feel it’s wrong or impolite to say no because we perceive it as a lack of appreciation.

Our Sprints became a mixture of everything. The Product Backlog was a mess, with wishes from everyone. Yet, stakeholders loved working with me; they saw me as friendly and supportive. What was wrong then?

I wasn’t doing a Product Manager’s job. I became a waiter trying to please everyone and ended up pleasing no one.

Let me share with you the importance of saying no. I will give you hints on when and how you can do that. I hope you get insights on how to apply it in your scenario by the end of this post.

Understanding Why Saying No Matters

It took me years to learn the importance of saying no. Today, I see that as a fundamental skill for Product Managers. And I would even say this is key for all team members.

Without the ability to say no, teams get distracted and have little chance of creating something outstanding.

James Clear, author of Atomic Habits, once said, “Every yes you say is a responsibility you get. And every no is a decision you make.” This quote resonates a lot with me. I continuously reflect to see if I’m blindly taking on a new responsibility or mindfully making a decision.

Nobody likes getting requests denied. I dislike it, and I am sure you do too. The challenge of saying no is how to handle the conflict it potentially creates. How can you overcome this trap?

Simplifying How You Say No

My initial approach was straightforward: Say no three times to every request. If something is important enough, the person will return the fourth time. This approach resulted in more focus and better results—But stakeholders perceived me as annoying, and my boss got frequent emails about it. Well, I don’t recommend this approach anymore.

A better way of saying no is to help people say no to themselves. Ask them specific questions that get them to reflect deeper. The secret behind it is genuine curiosity and interest. Some examples are:

• Which problem do you want to solve by doing that?
• How do users get this problem solved now?
• What would happen if we don’t help users solve this problem?
• Which potential business outcome can we drive?
• How do users care about this problem?
• I will have to stop working on feature X, leave it in the middle and invest more time later due to the context switch. Does that make sense?
• By doing what you say, I need to remove something from the current Sprint, which means  we will not reach the Sprint Goal. How do you feel about that?

When I ask these questions, people step back, reflect, and realize they lack such answers. They may ask my help with finding the answers, or even withdraw their request and reshape the idea.

How to Say No During Scrum Events

Scrum teams have many opportunities to say no to distractions and focus on what matters most. This skill is an essential one. Great teams master it, while mediocre ones keep saying yes to requests just because they can do it.

I’ve worked with dozens of teams, and the best ones continuously challenged each other on what to do and what not to do. They didn’t easily accept doing something just because they could. Their goal was always to identify which activities would yield more value.

Let’s look into Scrum Events and how teams could find opportunities to say no to distractions.

Daily Scrum

Every day, the Scrum team gets together to organize their work in order to get closer to the Sprint Goal. Curiously, most dailies I’ve attended lacked attention to the Sprint Goal. Typically, daily scrums last fifteen minutes, and depending on how you do them, the team can be distracted for the whole working day.

Product Owners generally master the art of bringing distractions to the team. I know that. I’ve done it several times. The secret to staying focused on the Sprint Goal is to challenge the team on how their issues help them reach their goal. Some examples:

• New Request: The Product Owner brings up either an idea or a new issue and tries to get the team to work on it. The best case would be for the Product Owner to challenge themself on how that contributes to the Sprint Goal. If not, don’t even bother sharing it. If that doesn’t happen, the team should ask this question and block the Product Owner.
• Tech Decisions: Sometimes, teams get stuck and fall into tech discussions. Such exchanges may result in decisions contradictory to the Sprint Goal. If one person would just ask how that relates to the Sprint Goal, I can assure you much unnecessary work would be avoided.

Sprint Planning

Many developers hate Sprint Planning because of the pressure of committing to output. The team can overcome this trap when they learn how to say no. 

Sprint Planning doesn’t need to be exhaustive; it should be inspiring and engaging.

Here’s how saying no can improve your planning:

• Don’t accept planning by capacity: Most Sprint Planning's start with the capacity question. The team can push back and focus on crafting the goal before selecting Product Backlog items.
• Leave space: Often, teams opt to keep items at the bottom of the backlog as “nice to have,” even though stakeholders would see everything as commitment. Scrum teams can simply say, “No. We’re not adding anything else. Once we reach our goal, we may consider other items. Not now.”
• New ideas: Sometimes, Product Owners come up with ideas out of the blue during Sprint Planning, which will trigger refinement and more tiring planning. This is another opportunity to say no. It should be an exception and not the rule. Planning and refining require a different mindset.

Sprint Review

How active are your stakeholders during your Sprint Reviews? The more involved they are, the more requests you receive. It’s vital to learn how to deal with them. Otherwise, you may become flooded with requests and many promises to fulfill.

I love it when stakeholders are engaged with Sprint Reviews. But you’ve got to learn how to receive feedback and distinguish between valuable insights and noise. Here are some opportunities to practice saying no:

• Solutions over problems: Depending on your storytelling, the whole Sprint Review may be focused on the solution space. Stakeholders will give you feedback on the solution, and many aspects will be opinions. I encourage you to ask them questions related to the problem space. For example, “Which problem do you want to address with that?” or “Would you have evidence this is the right thing to do?” Be creative with your questions.
• Commitment: Acting upon feedback is fundamental. Otherwise, your stakeholders will lose interest in Sprint Reviews. But that doesn’t mean you need to take notes and flood your Product Backlog. Strive to understand the need behind each feedback; hopefully, you have a Product Goal defined. If so, you could reflect on how the received feedback can help your team reach the Product Goal. Discard the ones unrelated to it.

Sprint Retrospective

Great Sprint Retrospectives end with action items to help the team strengthen their collaboration. Yet, you may uncover many opportunities to address and feel tempted to take more than you should.

You’ve also got a good chance of practicing saying no during Sprint Retrospectives. Here are some opportunities:

• Action items: Scrum Teams tend not to define actions by the end of Sprint Retrospectives, nor agree on too many actions. Great teams will ensure they only take actions doable by the end of the next Sprint.
• Action Definition: Agreeing upon an action is one thing. Having a crystal clear understanding of how to execute it is wholly different. Clear actions define who will do what by when and why that matters. More often than not, teams write actions that represent attitude. For example, “Whenever the Product Owner brings up a request, we strive to understand.”
• Action Carryover: I like to review the previous actions at the beginning of Sprint Retrospectives. Teams often don’t act upon something and want to keep items open and do it later. I perceive this as an opportunity to understand why the team didn’t take the agreed action instead of blindly carrying over. Again, another chance to say no.

Final Thoughts

I cannot emphasize enough the importance of mastering the art of saying no. When you’re afraid of saying no, you end up trapped. Your Product Backlog will be gigantic, your Sprints a mixture of everything, and stakeholders will have unrealistic expectations.

Saying yes is like sweeping the dust under the rug: You hide the problem, but you don’t solve it. Saying no will cause some conflicts, sure, but then you have a chance of solving them instead of losing your chances of creating an outstanding product.

Saying NO unlocks focus to deliver valuable solutions