A team charter and a working agreement are often used interchangeably, and the overlap is real enough that the distinction is worth being precise about, rather than treating them as two names for the same document.
The difference in scope
A working agreement is primarily operational: how the team wants to handle specific recurring situations (response times, core hours, how disagreements get resolved). A team charter sits one level up. It typically covers the team's purpose (why does this team exist, what outcome is it accountable for), its scope and boundaries (what's in scope for this team, what explicitly isn't), its stakeholders (who depends on this team, who does this team depend on), and only then, often as one section among several, its working norms.
Put simply: a working agreement answers "how do we work together." A charter answers "why does this team exist, and what does that imply about how we work."
Why the purpose section matters more than it seems
Teams that skip straight to working norms without first establishing genuine shared clarity on purpose often find their working-agreement discussions circular, because disagreements about "how we should work" are frequently disagreements about "what we think we're here to do" wearing a procedural disguise. A team that hasn't agreed whether its primary accountability is speed or quality will struggle to agree on norms for code review depth, release cadence, or how much time to spend on technical debt, not because the norms discussion is hard, but because the underlying purpose disagreement hasn't been surfaced.
Scope and boundaries prevent a specific, recurring failure
Teams without an explicit, agreed boundary on what's in and out of scope tend to accumulate work by drift: a request arrives, it's adjacent to what the team does, nobody has grounds to say no, and gradually the team's actual work diverges from its intended purpose without anyone deciding that should happen. A charter that states scope explicitly gives the team, and the Product Owner, actual grounds to decline or redirect work that doesn't fit, rather than relying on ad hoc judgment calls that different team members might make differently.
Stakeholder mapping as part of the charter, not an afterthought
Explicitly naming who the team serves and who it depends on, as part of the charter rather than as a separate exercise, keeps this information connected to the team's stated purpose. A team whose stated purpose is customer-facing reliability but whose actual stakeholder map is dominated by internal reporting requests has a visible mismatch worth addressing directly, and a charter that includes stakeholders alongside purpose makes that mismatch easy to spot.
When to write one, and when a working agreement is enough
A full charter is worth the investment for a new team forming around a new mandate, or an existing team whose purpose has genuinely become unclear or contested. A team that already has clear purpose and scope, and just needs to align on day-to-day norms, may not need the full charter exercise. A working agreement covering the operational questions is often sufficient. The charter is for establishing or re-establishing why the team exists; the working agreement is for how it operates once that's settled.