How to "Negotiate"? A super skill for Scrum Masters
A framework to help you get started
👋 Hello,
I’m Vibhor, and welcome to my weekly newsletter, the “Winning Strategy.” Each week I explore one question from you about agile, product, roles, processes, frameworks, career growth, working with humans and anything else that’s stressing you at your office. Send me your questions here, and in return, I’ll offer actionable, down-to-earth, and simple advice.
Q: There’s often a conflict between the Product Owner and the team regarding the sprint's scope. I tried using your conflict coaching cards, but those don’t fit this scenario. What to do?
Thanks for the question!
You’re right. I designed “Conflict Coaching Cards” to resolve conflicts between 2 individuals. Use those cards when there is a conflict based on:
Lack of trust
Unequal workload
Role ambiguity
Personal issues
Difference in work style
Lack of communication
Disagreement over a particular feature or approach
among many other conflicting scenarios.
The situation you have described is more like a misalignment of priorities between the Product Owner and the team (which makes it more than 2 people).
For the sake of simplicity and education, I am writing your detailed scenario below:
“Imagine that during a sprint planning meeting, the development team estimates that a particular user story will take two weeks to complete. However, the PO disagrees and insists that the user story can be done within 1 week. The PO argues that the story is simple and that the team is capable of completing it in less time.”
💡Tip: Whenever there is a disagreement between more than 2 people, try to divide the group into smaller groups, each favouring a single “point of view”.
Your role, then, as a Scrum Master is to “FACILITATE A NEGOTIATION”, between these groups using the IEU-EEA framework (detailed below) to easily guide all groups to converge on a mutual agreement.
The framework is visualized in the image below:
This post will be a live document. I’ll add to it as I learn new and effective tactics.
First. Identify the groups.
Before you can use the IEU-EEA framework, you need to identify the groups that disagree with each other.
To identify the groups, use the following process:
Observe
Identify key themes
Group team members based on their views
Confirm their views.
In your case, there are 2 groups:
The PO (group of 1 person)
The Dev team (Dev, QAs etc.)
Once you have your groups proceed to use the framework detailed below.
Let’s get into the details.
1. Identify the issue/s (I)
The first step is to identify/clarify the issue at hand and make sure everyone understands the problem.
You (the Scrum Master) can say:
“Let's pause for a moment here and figure out the problem we're up against. It appears that the dev team and PO have differing estimations regarding the amount of time it will take to complete this user story. Can we all agree on that?”
Use Fist of 5 to get the agreement.
2. Establish a common goal (E)
This is an important step.
Establishing a common goal helps in aligning the interests and priorities of different groups toward a shared objective. Common goal pulls collaboration.
You can say:
“Now, let’s identify a common goal that we can all agree on. To start, let’s say our common goal could be to deliver a valuable product increment to our customers. Does this align with everyone’s expectations and priorities?”
By saying the above, you set a tone for the discussion and establish an “example” shared objective. The groups can either agree to that example objective or decide to discuss further to find a shared objective.
You can help the team focus on the big picture and end customers’ needs.
Once you have a common goal, you can move the discussion to the next step.
3. Understanding each other’s perspective (U)
This step allows each group to explain their reasoning and concern behind their point of view.
In this case, the dev team explains why they are estimating the user story at 2 weeks, and the PO shares their angle for believing that the user story can be completed in 1 week.
You can start the discussion by saying:
“Now, let’s take some time to understand the differing perspectives. I would ask one person from the dev team to explain their reasoning behind 2 week's estimation. After that PO, can you please share your perspective as well behind 1 week?”
By saying this, you create a safe environment for both groups to express their views. It also encourages “active listening.”
Use Fist of 5 to confirm the understanding of both groups.
4. Explore potential solutions (E)
In this step, we brainstorm (or reverse brainstorm) potential solutions to the problem at hand.
Start the discussion by saying:
“Now that we have a better understanding of each other's perspective let's brainstorm potential solutions that could address the issue. Dev team, what are some solutions you suggest? PO, do you have any ideas for potential solutions?”
💡Tip: Following the suggestion, I often ask the team to overcome their decision bias by considering the trade-offs. For example, splitting the user story into smaller parts “may” lead to increased complexity.
Learn more about brainstorming techniques and reverse brainstorming in the following videos.
5 innovative brainstorming techniques
Reverse brainstorming
Once the team has a few solutions/suggestions/options, move to the next step.
5 . Evaluate solutions (E)
In this step, we evaluate all the potential solutions based on feasibility, impact, value and tradeoffs.
Start the discussion by saying:
"Now that we have a list of potential solutions let's evaluate each solution’s feasibility, impact, value and tradeoffs. How feasible is each solution? What impact will it have on the overall sprint goal? Will the solution meet both parties' needs?"
Saying this will ensure that the team considers the larger picture and the potential consequences of each solution.
An example list of solutions is shown below.
Once the team is done evaluating each potential solution, it’s time to move to the last step.
6. Agree on a course of action (A)
In this step, the team (PO + Dev) picks the solution with minimum risk and maximum value.
You can start the discussion by saying:
“Now that we have evaluated each potential solution let's reach a mutual agreement on a course of action that both groups can commit to. What solution(s) do we believe will best support the sprint goal and deliver value to the customer?"
By saying this, you ensure that all groups are focused on finding a solution that supports the common goal.
Use Fist of 5 to confirm the agreement.
This ends the process. You have successfully “Facilitated the negotiation” between the PO and the dev team.
📝 On a side note, what if the PO refuses to negotiate
As a Scrum Master, you can take the following steps:
Try to understand the PO’s reasoning behind the refusal. Perhaps the PO is under pressure to deliver that feature within a specific time frame
Involve the dev team. Don’t do it as a 1:1 with the PO
Document the issue, your actions, and attempt to negotiate
Escalate the issue to higher management or stakeholders for further discussion
Monitor the situation and continue working with the dev team and stakeholders to find a solution.
🧐 Here are some example situations where you may facilitate a negotiation:
Estimation disagreement
Product backlog prioritization
Sprint goal definition
Acceptance criteria
Technical debt
Change requests
Dependencies
This is it 🙏
This post contains a great deal of information, so don't worry about attempting to remember it all.
Consider it more of a reference guide or a source of inspiration for when you're generating ideas. And when you do come up with brilliant ideas, hit me up!
I am always open to suggestions and feedback. Pls, let me know if I missed something or if something seems odd.
🌟Also, if you share parts of the post on social media, I request you to please use proper credits. I won’t be as frequent in sharing this kind of content if I have to track copies of it floating around on social media.🌟
🙋🏻♂️ Your Questions!
If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.
If you’re finding this newsletter valuable, consider sharing it with friends or subscribing if you aren’t already.
Have a fulfilling and productive week 🙏
📌 Things I loved this Week
📚 Book - The Hard Thing About Hard Things by Ben Horowitz. In this book, Ben shares the difficult challenges he faced while building his companies and how he overcame them through perseverance and resilience. He offers practical and insightful advice on everything from raising capital to building company culture, and his approach is refreshingly honest and relatable. So if you're looking for inspiration and guidance to navigate the unpredictable realities of business and building products, don't miss out on this game-changing book!
🎙 Podcast - "Deep Questions #175" by Cal Newport. Cal has some awesome tips for making your work Zoom meetings not suck. One of his top suggestions is to avoid brainstorming in big groups because it might seem fun and collaborative, but it actually slows things down a lot. Instead, he recommends letting one person present their idea and then doing a Q&A session afterwards.
✍️ Quote of the Week
"Hard things are hard because there are no easy answers or recipes. They are hard because your emotions are at odds with your logic. They are hard because you don't know the answer and you cannot ask for help without showing weakness."
- Ben Horowitz, The Hard Thing About Hard Things.
“I share things I wish I knew in the starting years of my career in the corporate world"
Vibhor Chandel