Two Stakeholders, One Release: How to Resolve Priority Conflicts in Agile
When two stakeholders claim Priority One, Agile teams need more than diplomacy. A practical framework for surfacing conflict, using evidence-based decisions, and keeping delivery on track.
Nan Ross
7/14/20265 min read
In any high-stakes delivery environment, the phrase "Priority One" is frequently used as a blunt instrument rather than a strategic label. Teams often face a common impasse: two powerful stakeholders: perhaps one from Sales and another from Operations: each insisting their specific feature is the top priority for the upcoming release. When capacity only allows for one major initiative, the friction can stall momentum, erode trust, and force teams into a state of indecision.
The standard response in many organizations is to attempt to please everyone. This often leads to splitting the team’s focus or making a quiet, internal choice to favor one side over the other. Both approaches are detrimental. Splitting capacity ensures that neither feature arrives on time or with the necessary quality. Quietly picking a side forces the delivery lead into a business-level decision they are not authorized to make, inevitably destroying trust when the "losing" stakeholder discovers the delay too late.
The path forward requires a shift from diplomacy to transparent, evidence-based facilitation.
Stop Absorbing the Conflict: The Transparency Mandate
The most critical mistake a Product Owner or Scrum Master can make is absorbing the conflict between stakeholders. When a leader tries to manage these competing demands through separate, back-channel conversations, they become a buffer for the tension rather than a facilitator of a solution.
The first rule of conflict resolution in Agile is simple: Surface the conflict immediately.
Practitioners must operate from the foundational truth that a backlog is a single, ordered list. Item one, item two, and item three cannot all occupy the first position. Stating this obvious constraint out loud often shifts the dynamic of the conversation. It moves the problem away from interpersonal politics and centers it on the physical reality of team capacity.
If the person in charge is a Product Owner, the final decision rests with them. If the person is a Scrum Master or Business Analyst, the objective is not to decide, but to make the trade-off visible so the decision-maker can act with clarity. In either case, the move remains the same: stop having two separate conversations and force the conflict into the light.
The Unified Meeting: Eliminating the Echo Chamber
Conflict thrives in isolation. When stakeholders present their demands in one-on-one meetings, they focus entirely on their own needs without the context of the broader organization’s constraints. To break this cycle, practitioners should schedule a single, focused meeting containing both stakeholders simultaneously.
Short, high-intensity meetings are more effective than long, drawn-out negotiations. Bringing both parties into the same room (or virtual space) removes the opportunity for conflicting promises. It forces each stakeholder to hear the other's business case, which often leads to a natural softening of positions when the relative value of the competing request becomes apparent.
The Three Questions: Converting Opinion to Evidence
During the joint session, the goal is to strip away subjective adjectives like "critical," "urgent," and "essential." Instead, practitioners must demand evidence. Each stakeholder should be required to answer three specific questions:
What happens if the feature ships now?
What happens if the feature waits until the next release?
What evidence supports these claims?
This framework forces a transition from opinion-based shouting to data-driven decision-making. "My feature is priority one" is an opinion. "This feature protects a $200,000 renewal that closes in March" is evidence. Similarly, "Operations needs this" is an opinion, while "This manual process consumes 15 hours of staff time every week" is a measurable data point.
When both sides put real numbers and concrete dates on the table, the correct order usually reveals itself. The conversation shifts from "Who is more important?" to "Which outcome provides the most immediate value or prevents the greatest loss?"
Applying the Lightweight Scoring Model
If the three questions do not produce a clear winner, practitioners should employ a quantitative tie-breaker. A lightweight scoring model: inspired by Weighted Shortest Job First (WSJF): removes the personal element from the decision.
Teams should score each feature on a scale of 1 to 5 across three dimensions:
Business Value: What is the direct impact on revenue, customer satisfaction, or strategic goals?
Time Sensitivity: How quickly does the value decay if the feature is delayed?
Risk Reduction: Does this feature prevent a security breach, a compliance failure, or a technical collapse?
The sum of these three scores is then divided by the estimated effort or "job size." The initiative with the highest score is the logical priority. The math is not magic, but it provides a shared model that everyone can see and understand. No one "loses" to a rival stakeholder; instead, the initiatives are measured against a consistent business standard. This allows stakeholders to explain the decision to their own leadership teams without feeling undermined.
Securing Commitment and Closing the Loop
A decision without formal communication is just a rumor. Once the priority is established, the practitioner must close the loop in writing. A short message to both stakeholders should outline the order, the reasoning behind it, and: most importantly: the planned date for the second feature.
Avoid vague promises like "we will get to it eventually." This is a fast way to destroy professional trust. Instead, give the second stakeholder a real slot in the roadmap. For example: "Feature B is targeted for the next release cycle starting September 7th."
Practitioners must also acknowledge that priorities are allowed to change. If a deal falls through or a manual process worsens significantly, the conversation should be reopened using the same evidence-based framework. This is not a sign of indecision; it is the essence of Agile working as intended.
Beyond Theory: Mastering Real-World Delivery
Reading about conflict resolution is a world apart from facilitating a tense meeting between two department heads. Most Agile certifications focus on the mechanics of ceremonies: the "how" of Scrum: but leave practitioners unprepared for the "what if" scenarios of real-world delivery.
This is the gap filled by the Agile Product Delivery Lab.
The Lab is an 8-week live coaching program designed for Product Owners, Scrum Masters, and Business Analysts who are tired of theoretical fluff. Led by Nan Ross, practitioners dive into 16 real-time coaching sessions and three full Capstone Sprint simulations. This is where practitioners actually practice building a delivery portfolio, writing user stories, and navigating messy stakeholder conflicts like the one described above.
Participants don't just learn about Agile; they lead it. They master the integration of AI tools as thinking partners to speed up documentation and decision-making. By the end of the program, every participant leaves with the real artifacts and the "Human Moat" of experience that employers actually value.
Take Action Now
The difference between an Agile "student" and a delivery "leader" is the ability to handle the hard conversations. Stop letting "Priority One" inflation stall the team's progress. Surface the conflict, demand evidence, use the math, and communicate with authority.
For those ready to move from knowing the terms to leading the delivery, the next cohort of the Agile Product Delivery Lab is the place to start. Stop studying Agile and start delivering it.
Nan Ross
Agile Product Delivery & AI Adoption Expert. Helping leaders and teams turn ideas into working products with clarity, not chaos.
© 2026 Corporate Cosmo, LLC DBA NanRoss.com. All rights reserved.
My Books
Connect
Work with Nan