Scrum Teams Are Powerless Without Knowing When and How to Say No!
The more often teams say yes, the more distracted they become.
The more often teams say yes, the more distracted they become.
Originally published in GoRetro
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, yet it can be overwhelming.
Think about it for a minute. How often do you say yes? How does that impact the team 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 friendly and helpful. Yet, I missed the point. I was pleasing people and distracting the team.
Our Sprints became a mixture of everything. The Product Backlog was a mess. It had wishes from everyone. Yet, stakeholders loved working with me. They perceived me as friendly and supportive. What was wrong then?
I wasn’t doing a Product Manager 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 story.
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 of saying no, teams get distracted and have little chance of creating something outstanding.
James Clear, the 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 if I’m blindly taking 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 might you overcome this trap?
Simplifying How You Say No
My initial approach was straightforward. Say no three times to every request. If something is highly important, 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 e-mails about it. Well, I don’t recommend this approach anymore.
A better way of saying no is helping people say no to themselves. You 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?
When I ask these questions, people step back, reflect, and realize they lack such answers. They may ask my help to get these answers or even withdraw their request and shape the idea.
How to Say No During Scrum Events
Scrum teams have many opportunities of saying 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 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 to get closer to the Sprint Goal. Curiously, most dailies I’ve attended lacked attention to the Sprint Goal. Typically, dailies last fifteen minutes, and depending on how you do it, 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 that several times. The secret to keeping 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 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 herself 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. They should be inspiring and engaging.
Here’s how saying no can improve your planning:
Don’t accept planning by capacity: Most Sprint Plannings 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 on 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. This will trigger a refinement and more tiring planning. This is another opportunity to say no. I wouldn’t be black and white for this one, but this 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 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 of practicing 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. Yet, 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 up with actions 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.
Actions: Scrum Teams tend to define no actions by the end of Sprint Retrospectives or agree on too many actions. Great teams will ensure they only take actions doable by the end of the next Sprint.
Action Definition: One thing is agreeing upon an action. Another is having that crystal clear. 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 Owners brings a request, we strive to understand.”
Action Carryover: I like reviewing the previous actions at the beginning of Sprint Retrospectives. Teams often don’t act upon something and want to keep them open and do 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 will 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 throwing the dust under the rug. You hide the problem, but you don’t solve it. Saying no will cause some conflicts, 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
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊