---
title: "Team working agreements example by giffconstable"
source: Ways of Working (JPH)
source_url: https://github.com/joelparkerhenderson/ways-of-working
licence: CC0-1.0
domain: operating-models
subdomain: jph-ways-of-working
date_added: 2026-04-25
---

# Team working agreements example by giffconstable

[Getting Tactical: Product Team Working Agreements](https://giffconstable.com/2016/03/getting-tactical-product-team-working-agreements/)

"We talk a lot about how assumptions in business can kill you. But assumptions on a team can do the same. One of the best way to preserve a transparent, low-politics culture is to keep everything as visible and explicit as possible. This applies to strategy, vision, and values, but also to working methods."

[Example of the Team Working Agreement](https://docs.google.com/spreadsheets/d/1EYkSwnKVh_Y9207c_2FYSILXA6U-vUVq73hHmIe-yT0/edit?usp=sharing)

Process Overview:

* Agile Process Style: Scrum/XP
* Iteration Length: 1 week
* 20% Time: Yes

Ceremonies:

* Stand Up: Daily at 10am ET via videoconference
* Pre-IPM Meeting: Mondays at 10am ET with PM, engineering and design leads
* Iteration Planning Meeting: Mondays at 10am ET via videoconference
* Demo and OKR Review: Fridays at 4pm ET via videoconference
* Retrospectives: Every other Thursday at 4pm ET for 60 minutes with notes saved in Google Drive
* Roadmap Planning: Once a month

Communication/Tools

* Project Discussion: Slack
* Document Sharing / Artifact Saving: Google Drive
* Story Management: Pivotal Tracker
* Design Research: Trello
* Roadmap Planning: Physical board with cards (photograph and email / store in Drive)

Typical Working Hours:

* Team Overlap Time: 11am-5pm eastern
* Team Work Day: 9am-6pm local time

User Research:

* Customer Interviews: At least 2 individuals, bi-weekly; more for bigger initiatives
* Usability Testing: Prior to any major change
* Pre-Build Experiments: For all major new feature sets

User Stories:

* Ready for estimate when user story identifies:
  * Business outcome desired
  * Acceptance criteria
  * Identification of out of scope elements where needed to avoid confusion
  * If relevant: UI assets ready
* Primary user story writer: product manager
* Primary chore writer: Any team member
* Primary bug writer: Any team member
* Prioritization by: product manager, open for debate in Pre-IPM and IPM

Development:

* Pair Programming: Flexible
* Testing expectations:
  * Test Driven Development
  * Unit Tests
  * Integration Tests
  * Continuous Integration
* Refactoring: Continuous (Red-Green-Refactor model)
* Git Branching Model: Github flow
* Merge Policy: Independent reviewer merges based on pull request
* Ready for pull request when acceptance criteria met:
  * Tests written/passing
  * Primary development branch merged in
  * All tests passing

Work In Progress Limits:

* Backlog Size: Current iteration plus next iteration
* Icebox Size: 20 stories
* In Development: 1 story per pair
* Waiting For Acceptance: 4 stories

Deployment:

* Release cadence: Anytime, upon product owner acceptance
* Acceptance: Deployed in staging, tested and signed off on by product manager
* Deployed by: Development team or product manager
* Production support: none

Additional Agreements:

* Assume good intentions but always be on the lookout for process improvement opportunities
* Be present with each other even when working remotely
