Team Agreements: Definition of Done, Definition of Ready & Working Norms
Formal quality baselines ensuring zero unverified code merges into main branches while establishing documented operational procedures.
Establishing Verifiable Quality Baselines and Operational Procedures
Team agreements eliminate ambiguity about software readiness and peer expectations. In a regulated team, the Definition of Done (DoD) guarantees that zero unverified, untested, or undocumented code enters release branches. Simultaneously, the Definition of Ready (DoR) prevents engineering against vague requirements, while Working Agreements satisfy ISO 27001 Control A.5.37 documented operational procedures.
Definition of Done (DoD)
The Non-Negotiable Quality BaselineA formal agreement that defines when a user story is completely built, verified, documented, and ready for release.
Verifiable Checklist Items
- Clean Code: Code adheres to architecture standards and passes static analysis (linter / SAST) with zero high-severity issues.
- Automated Tests: Unit and integration tests written, passing in CI, with >= 85% branch coverage on new logic.
- Peer Code Review: Mandatory 2-person code review completed and approved, verifying segregation of duties.
- Design Inputs Traced: User story acceptance criteria verified against Software Requirements Specification (SRS).
- Documentation Updated: API docs, inline comments, and user-facing release notes updated.
- Security & SBOM: Dependency vulnerability scans passed, and Software Bill of Materials (SBOM) updated.
- Deployable: Increment deployed and verified in automated staging/QA environment.
Definition of Ready (DoR)
The Sprint Ingestion FilterA quality gate ensuring that a user story is sufficiently detailed, testable, and estimated before being committed in sprint planning.
Verifiable Checklist Items
- Clear Value Statement: Formatted as "As a [role], I want [feature], so that [benefit]".
- Testable Acceptance Criteria: Minimum 3 acceptance criteria written in Given/When/Then (Gherkin) format.
- Design Input Linkage: Cross-referenced to specific parent requirement or clinical workflow item in SRS.
- Dependencies Resolved: External APIs, UI wireframes, or data schemas are available.
- Estimated: Sized by the development team (e.g. story points <= 8 to fit within a single sprint).
- Security & Privacy Impact: Data sensitivity (PHI/PII) flagged and regulatory impact evaluated.
Team Working Agreements
Day-to-Day Engineering NormsExplicit agreements established by the team to govern communication, code review response times, and daily execution.
Verifiable Checklist Items
- Core Overlap Hours: 10:00 AM – 3:00 PM local time for synchronous collaboration, pairing, and meetings.
- PR Review SLA: Peer pull requests under 400 lines are reviewed within 24 business hours.
- Async-First Communication: Important technical decisions and architecture tradeoffs are documented in written ADRs.
- No Broken Builds: Broken CI pipelines take priority over new feature work; the entire squad assists until green.
- Blameless Post-Mortems: Incidents and defects are analyzed focusing on system/process resilience, not personal blame.
Regulated Team Manifesto
Shared Values & Cultural TenetsA high-level declaration of how the team balances engineering agility with human safety and regulatory rigor.
Verifiable Checklist Items
- Patient & User Safety First: We never sacrifice verification rigor or security controls to meet a deadline.
- Continuous Audit Readiness: We maintain compliance evidence in real-time as code is written, not before audits.
- Transparency: We surface risks, impediments, and defect escapes openly during retrospectives.
- Engineering Craftsmanship: We take pride in clean, modular, test-driven, and well-documented software.
Use this prompt to generate a custom Definition of Done tailored to your application's specific architecture and safety classification:
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.