Establish practice
Define cadence, owner, participation, and success signals for a recurring team practice.
Establish the practice
Define cadence, owner, participation, and success signals so the method works as a recurring team practice.
Variant for Operating practice. The plan is derived from method form, method steps, and runsheet.
RunsheetAn operating practice works through repetition. The cadence should be small enough to hold reliably.
The steps describe one repetition and are adjusted after review.
- 1
Section 1: Purpose and responsibilities
30-45 minTeam purpose in 1-3 sentences. Main responsibilities as 3-7 bullet points. Non-responsibilities explicit (what we do not do, even if others expect it).
OwnerNon-responsibilities are often more valuable than responsibilities. What we do not do clarifies escalation expectations. Avoid vague "we take care of everything" sentences. - 2
Section 2: Services and interfaces
45-60 minPer service: name, purpose, consumers, technical interface (API URL, Slack channel, ticket queue), request workflow. Three to eight services typical.
TeamServices are not only APIs. Consulting, reviews, on-call support are services too. Name consumers clearly, otherwise services are provided for wrong audience. - 3
Section 3: Service level and expectations
30-45 minRough SLA per service: response time, availability, escalation path. Expectations for consumers (for example issue template, on-call trigger conditions).
TeamSLAs must be achievable. Better conservative ("response within 2 business days") than aspirational. Unrealistic SLAs destroy trust faster than no SLAs. - 4
Section 4: Communication channels and escalation
20-30 minWhere consumers report requests, bugs, incidents. Purpose per channel (for example Slack #team-X for questions, Jira for tickets, PagerDuty for P1). Escalation hierarchy for conflicts.
TeamClear channel separation. "DM me on Slack" does not scale. Prefer public channels, documented histories secure knowledge. - 5
Section 5: Roadmap and onboarding
20-30 minCurrent roadmap section with next quarter focus. Onboarding notes: how can external team start with us (preparation, workshop, documentation).
TeamRoadmap section makes expectation management easier. Visibility over upcoming topics prevents repeated "when do you do X" questions.
Practice Charter
Copyable charter with purpose, cadence, owner, participation, flow, success signals, and review.
practice-charter.md
Practice Charter: Team API
Purpose
Helps clarify team boundaries, interfaces, and collaboration in concrete terms. It clarifies responsibility, interaction, and load between teams. The result is captured as a Team API document.
Cadence
weekly
Owner and Participation
- Owner: open
- Participants: Ein Team plus Stakeholder
- Mode: synchronous
Flow per Iteration
- Section 1: Purpose and responsibilities (30-45 min) Team purpose in 1-3 sentences. Main responsibilities as 3-7 bullet points. Non-responsibilities explicit (what we do not do, even if others expect it).
- Section 2: Services and interfaces (45-60 min) Per service: name, purpose, consumers, technical interface (API URL, Slack channel, ticket queue), request workflow. Three to eight services typical.
- Section 3: Service level and expectations (30-45 min) Rough SLA per service: response time, availability, escalation path. Expectations for consumers (for example issue template, on-call trigger conditions).
- Section 4: Communication channels and escalation (20-30 min) Where consumers report requests, bugs, incidents. Purpose per channel (for example Slack #team-X for questions, Jira for tickets, PagerDuty for P1). Escalation hierarchy for conflicts.
- Section 5: Roadmap and onboarding (20-30 min) Current roadmap section with next quarter focus. Onboarding notes: how can external team start with us (preparation, workshop, documentation).
Success Signals
Team-API-Dokument
Review
4 weeks