What is a working agreement?

A working agreement is a set of norms a development team commits to following — how work is defined as ready and done, how standups run, how code is reviewed, and how feedback flows. It makes shared expectations explicit so the team self-regulates instead of relying on a manager to enforce.

What is the difference between Definition of Ready and Definition of Done?

Definition of Ready lists what a backlog item needs before the team will start it — clear acceptance criteria, dependencies resolved, estimate agreed. Definition of Done lists what must be true before it counts as finished — tests passing, reviewed, deployed, documented. One gates entry, the other gates exit.

How specific should a Definition of Done be?

Specific enough that two people would agree whether an item meets it. Vague entries like 'tested' invite argument; 'unit tests added and CI green' does not. Each item should be objectively checkable, so done means done for everyone, not just the author.

How do we agree on code review turnaround?

Pick a target the team can realistically hold, such as reviewing open pull requests within one working day, and treat reviews as a priority rather than an interruption. A clear turnaround keeps work flowing and stops pull requests from going stale and piling up merge conflicts.

Should the whole team write the working agreement?

Yes. An agreement the team writes together is one they will actually follow, because they own it. Draft it collaboratively, revisit it in retrospectives, and update it whenever a norm stops serving the team. Imposed rules get ignored; agreed norms stick.

Agile Working Agreement Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Norms the team holds itself to

A working agreement is how an agile team replaces a manager standing over it with norms the team enforces itself. When everyone has agreed what ready means, what done means, and how reviews and feedback work, friction drops and work flows. The agreement is short, specific, and revisited in retrospectives so it keeps reflecting how the team actually wants to operate.

How it works

The builder covers the sections a development team needs. Definition of Ready is the gate a backlog item passes before work starts. Definition of Done is the gate it passes before it counts as complete. Both are checklists where every item should be objectively verifiable, so there is no argument about whether something qualifies.

The process sections capture your standup format, pull request norms, and the code review turnaround the team commits to. The feedback section records how the team gives and receives feedback so hard conversations have an agreed frame. The tool assembles everything into a single Markdown agreement, omitting any section you leave empty.

Tips and example

Keep each item checkable. A strong Definition of Done reads: “unit tests added, CI green, reviewed by one other engineer, merged to main, deployed to staging.” A weak one reads “works and is tested.” For reviews, commit to a number — “open pull requests reviewed within one working day” — and protect that time. Revisit the agreement every few sprints in your retro and prune anything the team has outgrown.