Conflict on a Scrum Team is the part of the Scrum Master accountability the framework says least about, since the word conflict appears nowhere in the 2020 Scrum Guide. Scrum.org still places the handling of it under the Developing People and Teams competency, checked on 8 October 2026, so a candidate has to take the material from team research outside the framework. Most of that material rests on one distinction. Karen Jehn separated task conflict from relationship conflict in Administrative Science Quarterly in 1995, and a team unable to say which one it is having usually answers both the same way.
Disagreement about the work and disagreement about people
Task conflict concerns the thing being built, and a Scrum Team is arranged to produce it. When two Developers disagree about whether a search service caches at the edge or inside the application, they have surfaced a decision the Sprint needed, so a team that settles it in ten minutes is working as designed. Relationship conflict concerns the people, which leaves nothing to decide and nothing for the Sprint to learn.
Scrum makes task conflict cheap and relationship conflict expensive. Cross-functional work puts a tester, a backend engineer and a designer inside the same decision several times a day, so a team that handles disagreement badly pays that cost daily. The five responses to conflict apply here as they do anywhere, and what Scrum changes is how often a team needs them.
What the Scrum Guide leaves to the Scrum Master
The Guide offers no procedure and one boundary. The Developers are structured and empowered by the organisation to manage their own work, so a Scrum Master who settles a disagreement for them has taken away the thing the accountability exists to build. Coaching the team in self-management appears on the list of services to the team, and deciding on the team's behalf appears on no list at all.
That boundary is what the scenario questions in this area turn on. If an option has the Scrum Master ruling on a technical disagreement, reassigning the disputed work or reporting the two people to a manager, it is describing somebody standing outside the accountability.
What a Scrum Master does when a team is in conflict
Four moves are available, ordered by how little each one takes away from the team.
- Making the disagreement discussable, by naming what appears to be happening and asking whether anybody else sees it.
- Separating the substance from the people, so that the team argues about caching and about release risk.
- Teaching the team a way to decide, such as agreeing in advance who settles a question the group cannot.
- Carrying the structural cause to whoever can change it, once the conflict turns out to be a symptom.
None of the four decides anything on the team's behalf. Carrying the structural cause outward looks like an exception and is not one, because what the Scrum Master acts on there is the structure around the team and never the argument inside it.
The limits of the Sprint Retrospective as the place for conflict
The Retrospective is the obvious venue, since its purpose is planning ways to increase quality and effectiveness, which is exactly what a team unable to work together has lost. Bringing a live disagreement into it works well when the disagreement is about how the team works.
Two limits matter all the same. A relationship conflict aired in front of six colleagues usually hardens, so the conversation that has to happen first is a private one. The Retrospective also arrives once a Sprint, which is far too slow for a conflict stopping work today, so the event is where a pattern gets examined and never where an urgent problem waits.
Conflict that is a symptom of something structural
Repeated conflict on a Scrum Team is usually structural, and two causes account for most of it. An unclear Product Goal leaves two Developers arguing about priority when the real gap is that nobody can say what the product is for, so the argument returns every Sprint whatever was agreed last time. A team that is not genuinely cross-functional produces the same effect for a different reason, because the one person holding the database skill becomes the point every disagreement routes through.
Both cases reward the same diagnosis. If the same two people argue about a different subject each Sprint, the subject is not the cause, and a Scrum Master who mediates each instance will be mediating for a year. The durable move is raising the structural cause with whoever owns it, which for a Product Goal is the Product Owner and for a missing skill is whoever staffs the team.