Skip to content

Latest commit

 

History

History
88 lines (65 loc) · 3.08 KB

index.md

File metadata and controls

88 lines (65 loc) · 3.08 KB
Raw

Team working agreements example by giffconstable

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

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