Team Agreements

Team agreements establish shared expectations and standards that enable effective collaboration. They should be created collaboratively, reviewed regularly, and enforced consistently.

Types of Team Agreements

Agreement	Purpose
Definition of Done (DoD)	When is work considered complete?
Definition of Ready (DoR)	When is work ready to start?
Working Agreement	How does the team work together?
Team Manifesto	What are the team's values and principles?

Definition of Done (DoD)

The Definition of Done is a checklist that every work item must satisfy before being considered complete.

Why It Matters

Ensures consistent quality
Prevents "almost done" syndrome
Creates shared understanding
Supports compliance requirements

Example Definition of Done

## Code Complete
- [ ] All acceptance criteria met
- [ ] Code follows style guide
- [ ] No compiler warnings
- [ ] Self-reviewed before PR

## Code Reviewed
- [ ] PR created with description
- [ ] At least 1 approval
- [ ] All review comments addressed

## Tested
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Manual testing completed
- [ ] No critical/high bugs

## Documented
- [ ] Code comments for complex logic
- [ ] API documentation updated
- [ ] README updated if needed
- [ ] User documentation updated

## Deployed
- [ ] Merged to main branch
- [ ] Deployed to staging
- [ ] Smoke tests passing
- [ ] No performance regression

DoD for Regulated Software

Additional criteria for FDA/HIPAA/FedRAMP:

## Compliance
- [ ] Traceability matrix updated
- [ ] Design documentation current
- [ ] Risk assessment reviewed
- [ ] Change request documented
- [ ] Approval signatures obtained

Definition of Ready (DoR)

The Definition of Ready specifies when a backlog item can be pulled into a sprint.

Why It Matters

Prevents starting unclear work
Reduces mid-sprint surprises
Improves estimation accuracy
Saves time during planning

Example Definition of Ready

## Requirements
- [ ] User story clearly written
- [ ] Acceptance criteria defined
- [ ] Dependencies identified
- [ ] No blocking questions

## Design
- [ ] UI/UX mockups available (if applicable)
- [ ] Technical approach discussed
- [ ] API contracts defined (if applicable)

## Estimation
- [ ] Story sized by team
- [ ] Fits within single sprint
- [ ] Team understands the work

## Validation
- [ ] Product Owner approved
- [ ] Test approach identified
- [ ] Edge cases considered

Working Agreement

A working agreement defines how the team collaborates day-to-day.

Core Areas to Address

Communication

How do we communicate? (Slack, email, in-person)
What's our response time expectation?
When are meetings vs. async appropriate?

Meetings

What ceremonies do we hold?
What's our meeting etiquette?
How do we handle time zones?

Code & Quality

What's our branching strategy?
How do we conduct code reviews?
What's our testing standard?

Conflict Resolution

How do we raise concerns?
How do we make decisions?
When do we escalate?

Example Working Agreement

# Team Alpha Working Agreement

## Communication
- Primary: Slack (#team-alpha)
- Urgent: Direct message or call
- Response time: 4 hours during work hours
- No Slack after 6 PM unless critical

## Meetings
- Cameras on for ceremonies
- 5-minute grace period, then start
- One person talks at a time
- Summarize decisions in writing

## Code Practices
- PRs reviewed within 24 hours
- All tests must pass before merge
- No direct commits to main
- Pair on complex problems

## Work Hours
- Core hours: 10 AM - 3 PM (overlap)
- Respect focus time (no meetings)
- Take breaks - no judgment

## Conflict
- Raise concerns in retro
- Disagree and commit
- Escalate to manager if unresolved after 48h

Team Manifesto

A team manifesto captures the team's values and principles—the "why" behind the practices.

Creating a Manifesto

Brainstorm values that matter to the team
Prioritize the top 5-7 values
Define what each value means in practice
Commit to living by the manifesto
Review quarterly and update

Example Team Manifesto

# Team Alpha Manifesto

## We Value...

### Quality Over Speed
We don't sacrifice quality for deadlines. If we can't do it right,
we communicate early and adjust scope.

### Psychological Safety
Everyone can speak up without fear. Mistakes are learning
opportunities, not blame targets.

### Sustainable Pace
We work sustainable hours. Crunch is a failure of planning,
not a badge of honor.

### Continuous Improvement
We reflect regularly and act on our learnings.
Status quo is not good enough.

### Collective Ownership
The whole team owns the code, the quality, and the outcomes.
No heroes, no silos.

### Transparency
We share information openly. Bad news doesn't get better with age.

Implementing Agreements

Creating Agreements

Schedule dedicated time (1-2 hours)
Facilitate collaboratively
Seek consensus, not majority
Document clearly
Make visible (post on wall/wiki)

Reviewing Agreements

Review quarterly or when team changes
Use retrospectives to identify issues
Update based on team learning
Remove items that aren't used

Enforcing Agreements

Reference in day-to-day work
Call out when agreements aren't followed
Discuss violations constructively
Update if agreements don't work

Agreement Anti-Patterns

Too Detailed

50-item DoD that no one reads
Working agreement that's a novel
Fix: Keep it concise and actionable

Never Updated

Agreements from 2 years ago
Team has changed, agreements haven't
Fix: Schedule regular reviews

Not Enforced

Agreements exist but aren't followed
No accountability
Fix: Make agreements visible, call out violations

Imposed, Not Created

Manager wrote the agreements
Team doesn't feel ownership
Fix: Create collaboratively

Templates

Definition of Done Template

# Definition of Done

## Development
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Review
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Testing
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Documentation
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## Deployment
- [ ] [Criterion 1]
- [ ] [Criterion 2]

Working Agreement Template

# Working Agreement

## Communication
- [How we communicate]

## Meetings
- [Meeting norms]

## Code Practices
- [Development standards]

## Work Hours
- [Time expectations]

## Conflict Resolution
- [How we handle disagreements]

Last Updated: [Date]
Participants: [Names]

This section fulfills ISO 13485 requirements for quality policy documentation (5.3), resource competence (6.2), and work environment controls (6.4), and ISO 27001 requirements for documented operating procedures (A.5.37), information security roles and responsibilities (A.5.2), and acceptable use of information (A.5.10).

View full compliance matrix

On this page