Conflict Resolution

Conflict Resolution Interview with follow-up questions

1. Can you describe a situation where you had to resolve a conflict within your Scrum team?

In one team I worked with, two Developers had a persistent disagreement about testing approach—one believed the team should write unit tests for every piece of logic; the other felt this was slowing delivery and that integration tests were sufficient. The conflict had been simmering for weeks and was starting to affect collaboration.

My first move was to talk to each person individually. Not to mediate yet, but to understand: what was each person actually worried about? It turned out the disagreement wasn't really about testing philosophy—one Developer was worried about technical debt accumulating and the other was worried about the Sprint Goal consistently slipping. Both concerns were legitimate.

I brought this into the Retrospective as a topic the team needed to address together, framing it as a question about the Definition of Done rather than a personal conflict. The Definition of Done is the team's shared commitment about what "done" means for an Increment—so the testing question was actually a DoD question, which the 2020 Scrum Guide says the Scrum Team creates and owns.

The team discussed it, with both Developers presenting their concerns to the group rather than to each other. Other Developers weighed in. The outcome was a revised Definition of Done that specified a minimum unit test coverage threshold for core logic and left integration-test decisions to the team's judgment per item.

Framing it through the DoD depersonalized the conflict—it became a team process question rather than a disagreement between two individuals. Both Developers felt heard because their underlying concerns (quality and pace) were addressed in the outcome.

The interviewer follow-up worth preparing for: what do you do if the conflict is personal rather than technical? The answer is that I deal with personal conflicts directly—privately, with both parties, focused on behavior and impact rather than character—and I bring in the Scrum Team's values (respect, openness) explicitly when I need to.

↑ Back to top

Follow-up 1

How did you approach the situation?

To approach the conflict resolution situation within my Scrum team, I followed these steps:

  1. Scheduled a meeting with the conflicting team members to understand their perspectives and concerns.
  2. Facilitated an open and respectful discussion, allowing each team member to express their views.
  3. Encouraged active listening and ensured that everyone had an opportunity to speak.
  4. Facilitated a brainstorming session to find a compromise, considering the impact of each user story on the project goals and the potential risks associated with different prioritizations.
  5. Helped the team members understand each other's viewpoints and find a middle ground.
  6. Made a decision based on the impact on project goals and urgency of business needs.
  7. Documented and communicated the decision to the entire team.

Follow-up 2

What was the outcome?

The outcome of the conflict resolution within my Scrum team was a mutual agreement on adjusting the priority of the user stories. By considering the impact on project goals and the urgency of business needs, we were able to find a middle ground that satisfied both team members.

This outcome resulted in improved collaboration and a more harmonious working environment within the team. The team members were able to move forward with a shared understanding and a renewed focus on achieving project objectives.

Follow-up 3

What would you do differently if faced with a similar situation in the future?

If faced with a similar conflict resolution situation in the future, I would consider the following improvements:

  1. Actively involve the Product Owner or stakeholders in the discussion to gain additional insights and perspectives.
  2. Implement a more structured decision-making process, such as using a prioritization matrix or a voting system, to ensure fairness and transparency.
  3. Provide ongoing support and follow-up to ensure that the resolution is implemented effectively and any lingering issues are addressed.
  4. Continuously promote a culture of open communication and collaboration within the team to prevent conflicts from escalating.

By implementing these improvements, I believe that the conflict resolution process can be further enhanced, leading to even better outcomes and stronger team dynamics.

2. What strategies do you use to prevent conflicts within the team?

Conflict prevention in a Scrum team is primarily about building the conditions where problems surface early and are addressed directly, rather than festering. The Scrum framework itself creates several of those conditions—my role is to make sure they actually work.

Use the Scrum events as early warning systems. The Daily Scrum, done well, gives the Developers a daily opportunity to surface blockers and misalignments before they compound. The Retrospective is the team's dedicated space to examine interpersonal and process friction. If these events are treated as formalities—status updates and blame sessions—they lose their prevention value. I invest in making them psychologically safe and genuinely useful.

Make commitments and accountabilities clear. Many conflicts arise from ambiguity about who owns what. The 2020 Scrum Guide defines three accountabilities: Product Owner, Scrum Master, and Developers. Within the Developers, the team is self-managing—they decide how to divide the work. When people are unclear about who is responsible for a decision, they either duplicate effort or leave gaps, both of which breed conflict. I make these boundaries visible and revisit them when friction appears.

Protect the Scrum values. Commitment, Focus, Openness, Respect, and Courage are not decorative. When a team member is being dismissed in a discussion or a concern is being minimized, I name it. Letting small disrespects accumulate is a conflict-creation pattern, not just a culture issue.

Address early signals. The Retrospective action items that teams least want to discuss are usually the ones that matter most. I notice when a team skips a topic that came up in the previous Sprint and I create space for it.

Build trust outside of meetings. Trust reduces the cost of disagreement. Teams where people know each other as people—not just task-holders—handle friction more productively. I encourage working sessions, pair collaboration, and occasional non-work interaction, especially in distributed contexts.

Prevention is never complete. The goal is not a conflict-free team but a team that catches friction early and resolves it without it becoming destructive.

↑ Back to top

Follow-up 1

Can you provide an example where these strategies were effective?

Certainly! In a previous project, there was a disagreement between two team members regarding the approach to be taken for a particular task. Instead of letting the conflict escalate, I encouraged both team members to openly discuss their ideas and concerns. By actively listening to each other and facilitating a constructive conversation, we were able to find a middle ground that incorporated the strengths of both approaches. This not only resolved the conflict but also resulted in a more innovative solution that exceeded our initial expectations. By using open communication and fostering a collaborative team culture, we were able to turn a potential conflict into a positive outcome.

Follow-up 2

How do you ensure these strategies are implemented consistently?

To ensure that these strategies are implemented consistently, I believe in leading by example. I demonstrate open communication by actively listening to team members, providing constructive feedback, and encouraging them to express their thoughts and concerns. By consistently modeling this behavior, I set the expectation for the team to follow suit.

I also believe in regular team meetings and check-ins to address any potential conflicts or issues. These meetings provide a platform for team members to discuss their challenges, share updates, and seek support. By consistently facilitating these meetings and encouraging open dialogue, I create a space where conflicts can be addressed and resolved in a timely manner.

Furthermore, I believe in providing ongoing training and development opportunities for the team. This includes workshops on effective communication, conflict resolution, and teamwork. By investing in the team's skills and knowledge, I ensure that they have the tools and resources to prevent and manage conflicts effectively.

Overall, by consistently demonstrating and reinforcing these strategies, I create a team culture that values open communication, collaboration, and clarity, leading to a consistent implementation of conflict prevention strategies.

3. How do you handle a situation where a team member is not agreeing with the rest of the team?

My starting assumption is that a team member who disagrees with the rest of the team might be right. The 2020 Scrum Guide describes the Scrum Team as self-managing, and that requires the team to genuinely process dissenting views rather than suppress them in the name of consensus. So my first move is to ensure the disagreement gets a real hearing, not to get the dissenter to come around.

Understand the concern before doing anything else. I'll speak with the person privately first—not to talk them out of their position, but to understand what's driving it. Is it a technical risk the rest of the team hasn't seen? A past experience that's shaping their read of the situation? A value conflict? The nature of the concern changes what I do next.

Create structured space for the disagreement. In a team setting, dissent often gets steamrolled simply because the group has momentum. I use facilitation techniques—round-robin input before open discussion, writing ideas before sharing them verbally—that give the dissenting view equal airtime.

Separate the person from the position. If the team is reacting to the individual ("that's just how they always are"), I redirect to the substance: "Setting aside who said it—is this concern worth examining on its merits?"

Distinguish between "I don't agree" and "I can't commit." The 2020 Scrum Guide names Commitment as a core Scrum value. A team member who disagrees but can still commit to trying the approach for one Sprint and revisiting it in the Retrospective is in a fundamentally different position from someone who will not engage. The first is healthy; the second needs a direct conversation.

Use the Retrospective as the right venue for persistent disagreements. If the same concern keeps surfacing, it belongs in the Retrospective as a team process topic rather than a recurring point of friction in Sprint events.

What I avoid: using my facilitation role to create artificial consensus or making the dissenter feel that disagreement itself is the problem. Psychological safety depends on people believing that speaking up is safe, even when they're in the minority.

↑ Back to top

Follow-up 1

What steps do you take to understand the perspective of the disagreeing team member?

To understand the perspective of a team member who is not in agreement, I would take the following steps:

  1. Active listening: I would actively listen to the team member's concerns and opinions without interrupting or judging. This involves giving them my full attention, maintaining eye contact, and using verbal and non-verbal cues to show that I am engaged.

  2. Ask open-ended questions: I would ask open-ended questions to encourage the team member to elaborate on their perspective. This can help me gain a deeper understanding of their thoughts, motivations, and concerns.

  3. Empathy and perspective-taking: I would try to put myself in the team member's shoes and understand their point of view from their own context and experiences. This involves showing empathy and considering their unique circumstances.

  4. Seek additional information: If needed, I would gather more information or data to support or challenge the team member's perspective. This can help in making an informed decision and addressing any misconceptions or gaps in understanding.

By taking these steps, I aim to understand the perspective of the disagreeing team member and create an environment where their voice is heard and valued.

Follow-up 2

How do you ensure that the team member feels heard and valued?

To ensure that a team member feels heard and valued, I would take the following actions:

  1. Active listening: I would actively listen to the team member's concerns, ideas, and feedback. This involves giving them my full attention, maintaining eye contact, and providing verbal and non-verbal cues to show that I am engaged.

  2. Validate their perspective: I would acknowledge and validate the team member's perspective, even if I may not fully agree with it. This can be done by expressing appreciation for their input, summarizing their points, and recognizing the value they bring to the team.

  3. Encourage participation: I would actively encourage the team member to participate in team discussions and decision-making processes. This can be done by inviting their input, asking for their opinions, and creating opportunities for them to contribute their expertise.

  4. Provide feedback and recognition: I would provide regular feedback to the team member, highlighting their strengths and areas of improvement. Additionally, I would recognize their contributions and achievements, both privately and publicly, to show that their efforts are valued.

  5. Support their professional growth: I would support the team member's professional growth by providing opportunities for learning and development. This can include training programs, mentorship, or assigning them challenging tasks that align with their interests and goals.

By implementing these actions, I aim to create an inclusive and supportive environment where every team member feels heard, valued, and motivated to contribute their best.

4. How do you manage conflicts between the Product Owner and the team?

Conflicts between the Product Owner and the Developers are among the most common and consequential in Scrum, and they often trace back to unclear accountability boundaries. The 2020 Scrum Guide is precise: the Product Owner decides what the team works on and in what order; the Developers decide how to do the work and how much they can take on in a Sprint. When those boundaries are respected, many conflicts don't arise in the first place.

Diagnose the type of conflict. Is the Product Owner pushing the Developers to take on more than they can deliver? Is there a disagreement about whether something is "done"? Is the Product Owner bypassing the Sprint Goal mid-Sprint? Each pattern has a different response.

For scope and capacity conflicts, I help the Developers articulate their capacity concerns in concrete terms—not as resistance, but as a realistic assessment that the Product Owner needs to plan around. If the Product Owner doesn't trust the team's estimates, that's a deeper trust issue worth addressing directly in a Retrospective.

For mid-Sprint scope changes, the Scrum Guide is clear: the Product Owner can negotiate scope with the Developers, but cannot unilaterally change the Sprint Backlog in ways that would undermine the Sprint Goal. I enforce this structure not to protect the Developers from the Product Owner, but because eroding the Sprint Goal every Sprint destroys the team's ability to make reliable commitments.

For Definition of Done conflicts—where the Product Owner wants to ship something the Developers don't consider done—I anchor the conversation to the DoD as the team's shared standard. Work that doesn't meet the DoD is not an Increment. That's not a Developer preference; it's the framework.

Facilitate, don't arbitrate. My role is not to rule in favor of the Developers or the Product Owner. It's to create a structured conversation where both parties can surface their real concerns and find a resolution grounded in the Sprint Goal and Product Goal.

Name the pattern, not just the instance. If the same conflict keeps recurring, it's a signal about something structural—unclear expectations, insufficient refinement, or a misunderstood accountability. The Retrospective is where that structural issue belongs.

↑ Back to top

Follow-up 1

Can you share an example of such a conflict and how you resolved it?

Sure! Here's an example of a conflict between the Product Owner and the team:

The Product Owner wanted to prioritize the implementation of a new feature that would require significant development effort. However, the team believed that addressing technical debt and improving the overall stability of the product should be the top priority.

To resolve this conflict, I facilitated a meeting between the Product Owner and the team. During the meeting, both parties expressed their concerns and perspectives. I encouraged active listening and ensured that everyone had an opportunity to speak.

After understanding the root cause of the conflict, I helped the Product Owner and the team identify the risks and benefits associated with each option. We discussed the impact on customer satisfaction, technical debt, and the long-term viability of the product.

Through this discussion, the team was able to provide data and insights that convinced the Product Owner to prioritize addressing technical debt first. The Product Owner agreed to allocate a portion of the sprint to address technical debt while still making progress on the new feature.

By involving the team in the decision-making process and considering their expertise, we were able to find a compromise that satisfied both the Product Owner and the team.

Follow-up 2

How do you ensure that both the Product Owner and the team are satisfied with the resolution?

To ensure that both the Product Owner and the team are satisfied with the resolution of a conflict, it is important to involve them in the decision-making process and consider their perspectives. Here are some strategies to achieve this:

  1. Active listening: Actively listen to the concerns and perspectives of both the Product Owner and the team. Ensure that everyone feels heard and understood.

  2. Collaboration: Encourage collaboration and open dialogue between the Product Owner and the team. Facilitate discussions where both parties can contribute their ideas and suggestions.

  3. Data-driven decision making: Use data and objective information to support the resolution. Present facts, metrics, and customer feedback to help both the Product Owner and the team make informed decisions.

  4. Compromise: Encourage both parties to find a middle ground and be willing to compromise. Help them understand the trade-offs and benefits of different options.

  5. Regular feedback loops: Establish regular feedback loops to evaluate the effectiveness of the resolution. Encourage continuous improvement and adjust the approach if needed.

By following these strategies, you can increase the likelihood of achieving a resolution that satisfies both the Product Owner and the team.

5. How do you handle conflicts that arise due to differing priorities or goals within the team?

Priority conflicts within a Scrum team often look like interpersonal disagreements but are usually symptoms of an unclear Product Goal, an insufficiently ordered Product Backlog, or ambiguity about who holds which accountability. Addressing the root cause is more effective than managing the surface conflict.

Anchor to the Sprint Goal and Product Goal. The 2020 Scrum Guide establishes these as the team's shared commitments. When team members have competing priorities, the first move is to ask: which option better serves the Sprint Goal? If that's genuinely unclear, then the Sprint Goal itself may be the problem—too vague to serve as a decision criterion. A sharper Sprint Goal is sometimes the real resolution.

Clarify accountabilities before facilitating the conflict. Priority decisions about the Product Backlog belong to the Product Owner. If Developers are arguing about which PBI to work on, I first check whether this is a question the Product Owner should have already resolved through backlog ordering. If it is, I bring it back to the Product Owner rather than letting the Developers debate it.

Distinguish between priority conflicts and resource conflicts. Sometimes what looks like a disagreement about what matters most is actually a disagreement about who is doing what. Separating these makes both easier to resolve.

Use Retrospectives to address recurring priority friction. If the same type of conflict comes up Sprint after Sprint—for example, technical debt work consistently losing out to feature work, or testing getting deferred—that's a structural issue about how the team and Product Owner order the backlog. I bring it to the Retrospective as a team-level discussion and help the team agree on explicit policies (for example, a percentage of capacity reserved for technical debt) that reduce per-Sprint friction.

Respect Commitment as a Scrum value. Once the Sprint Goal is set in Sprint Planning, the team has committed to it. Priority conflicts that would undermine the Sprint Goal mid-Sprint need to be escalated quickly—either the scope is renegotiated with the Product Owner, or the conflict is deferred to the next Sprint. The team cannot simply re-prioritize on their own without involving the Product Owner in that conversation.

↑ Back to top

Follow-up 1

Can you provide an example where you had to deal with such a conflict?

Certainly! In my previous role as a project manager, I had a situation where the development team wanted to prioritize adding new features to the product, while the marketing team wanted to focus on improving the product's user interface. Both teams had valid reasons for their priorities, but it created a conflict.

To address this, I scheduled a meeting with representatives from both teams to discuss their perspectives and concerns. During the meeting, we identified that both teams shared a common goal of enhancing the user experience. We then brainstormed ideas to achieve this goal while also incorporating the desired new features.

Through open communication and collaboration, we were able to find a solution that satisfied both teams. We decided to prioritize the user interface improvements in the next sprint while also allocating some resources to work on the new features. This compromise allowed us to align the team towards a common goal while addressing the differing priorities.

Follow-up 2

What strategies do you use to align the team towards a common goal?

To align the team towards a common goal, I employ the following strategies:

  1. Clearly communicate the goal: I ensure that every team member understands the overall objective and the importance of their contribution towards achieving it.

  2. Foster a shared vision: I encourage team members to envision the end result and the positive impact it will have, creating a sense of shared purpose.

  3. Break down the goal: I break down the goal into smaller, manageable tasks and assign them to team members based on their strengths and expertise.

  4. Encourage collaboration: I promote collaboration and open communication among team members, encouraging them to share ideas, provide feedback, and support each other.

  5. Regularly track progress: I set milestones and regularly track the team's progress towards the goal, providing feedback and guidance as needed.

By implementing these strategies, I aim to create a cohesive and motivated team that is aligned towards a common goal.

Live mock interview

Mock interview: Conflict Resolution

Intermediate ~5 min Your own free AI key

Your voice and your AI key never touch our servers; the key stays in this browser and is sent only to Google. Only your round scores are saved to track progress.