T12: Ground Rules | Domain 1

📖 Lý thuyết / Theory

🇺🇸 English

Ground rules (also called "team norms" or "working agreements") are explicit agreements about how the team will work together. They reduce ambiguity, prevent conflicts from escalating, and create psychological safety.

Key principle: Ground rules should be created by the team, not imposed by the PM. When the team owns the rules, they enforce them internally.

In Agile: team ground rules are often part of the team charter or sprint kickoff. They're reviewed and updated in retrospectives.

Reference: PMI — Ground Rules for Effective Teams

🇻🇳 Tiếng Việt

Ground rules (cũng gọi là "team norms" hay "working agreements") là những thỏa thuận rõ ràng về cách team làm việc cùng nhau. Chúng giảm mơ hồ, ngăn xung đột leo thang và tạo ra tâm lý an toàn.

Nguyên tắc chính: Ground rules nên được tạo ra bởi team, không phải áp đặt bởi PM. Khi team sở hữu các quy tắc, họ tự thực thi nội bộ.

🔧 Working Agreement Template

Team Working Agreement — Project Alpha

Last updated: 2026-05-01 | Reviewed in Sprint Retro COMMUNICATION • All work discussions in English (written and meetings) • Respond to Slack @mentions within 4 business hours • Document decisions in Confluence — "if it's not written, it didn't happen" • Standup daily at 9:30 AM; async update in Slack if absent CODE & TECHNICAL • PR review within 24 hours (2 approvals required) • No direct push to main; all changes via PR • Squash merge only; delete branch after merge • ADR required for any architectural decision • Test coverage ≥80% for new code MEETINGS • Start on time; end on time or earlier • Agenda shared 30 min before meeting • No phones/laptops during standup (unless async) • Action items written in meeting notes before meeting ends BEHAVIORS • Raise blockers immediately — no suffering in silence • Assume positive intent; ask before interpreting • Constructive critique: focus on code/design, not person • No "buts" after feedback — hear it fully first SPRINT COMMITMENT • No gold-plating — deliver what was committed, not more • Flag scope concerns in planning, not mid-sprint • Help teammates before picking up new work (team > individual)

💼 Thực chiến / Scenario

🏢

FinTech Company X — Sprint 1 Team Working Agreement Workshop

Tình huống: Project Alpha kickoff. PM tổ chức 2-giờ working agreement workshop với toàn team (không phải PM tự viết rules rồi share).

Workshop format: PM chia nhóm nhỏ thảo luận: "What makes a team work well together? What have you seen that DOESN'T work?" Mỗi nhóm present, PM facilitate, team vote bằng dot-stickers trên Miro. Top-voted items trở thành working agreements. Document và post trên Confluence.

Key outcome: Team owns the agreements. Khi ai đó vi phạm (ví dụ: không review PR trong 24h), TEAM tự nhắc nhở lẫn nhau — không cần PM enforce. Đây là ground rules created by team, not imposed by manager.

✏️ Practice Questions

Question 1

Team members frequently have disagreements about meeting etiquette, communication channels, and code review processes. What should the PM do to address this?

A. Create and distribute a policy document defining all team rules
B. Facilitate a team workshop to collaboratively define working agreements and ground rules
C. Let the team self-organize without formal rules, as rules are bureaucratic in agile
D. Address each disagreement individually as they arise

✅ Answer: B — Working agreements created collaboratively by the team have greater buy-in and are more likely to be followed. Option A (PM creates rules unilaterally) doesn't create ownership. Option C (no rules) causes ongoing friction. Option D is reactive and inefficient — addressing each issue individually misses the systemic fix.

Question 2

A new virtual team of 8 people from two different countries starts a project. What is the BEST time to establish working agreements?

A. After the first conflict arises
B. During the team kickoff, before work begins — when people are most receptive and norms are not yet set
C. After the first sprint is completed
D. Working agreements are only needed for co-located teams

✅ Answer: B — Ground rules should be established early and proactively, before negative patterns form. At kickoff, the team has no entrenched habits and is most open to setting norms together. Waiting for a conflict (A) or after the first sprint (C) is reactive. Virtual teams (D) actually need working agreements more than co-located teams because informal cues and spontaneous conversations are absent.

Question 3

A working agreement states 'respond to Slack messages within 4 hours during business hours.' One team member consistently responds after 24 hours, causing blockers. What should the PM/SM do?

A. Remove the 4-hour rule since it's too strict
B. Ignore it — everyone works differently
C. Address the violation directly with the individual first (private conversation), and if persistent, raise it as a team agreement issue in retrospective
D. Immediately escalate to HR

✅ Answer: C — Working agreements only work if they are enforced respectfully. The first step is a direct, private conversation with the individual — there may be a valid reason (time zone confusion, workload) that can be resolved without escalation. If the behaviour continues, the retrospective is the right forum to revisit the agreement as a team. Abandoning the rule (A, B) signals agreements are optional. HR escalation (D) is premature for a first offence.

🤖 AI Tools for PMs

🤖

How AI Augments This Process

AI helps PMs facilitate team norm-setting sessions, draft working agreements, analyze rule violations patterns, and generate team charter content.

Sample Claude Prompts

Team charter / ground rules facilitation I'm facilitating a session to define team ground rules / working agreement. Team context: [size, new team / existing team, any known issues] Common friction areas (from experience or retros): [meetings / communication / quality / decision-making / work hours] Team's working style diversity: [introverts/extroverts, different cultural backgrounds, seniority mix] Design a 45-minute facilitation session to co-create ground rules: 1. Opening: why ground rules matter (3 min) 2. Individual reflection: what do you need to do your best work? (5 min) 3. Share out and cluster themes (15 min) 4. Prioritize and refine top 8-10 rules (15 min) 5. Commitment ritual and publishing (7 min) Include specific facilitation prompts and how to handle disagreement on specific rules.

Ground rule violation handling A team member is repeatedly violating a team ground rule: [specific rule, e.g., "cameras on during standup" / "respond to Slack within 4 hours" / "don't interrupt during meetings"]. Frequency: [how many times, over what period] Impact: [how it affects team dynamics or work] My previous actions: [what I've said or done so far] Their context: [any mitigating factors I'm aware of] Help me: 1. Decide the right approach (private conversation / team conversation / formal feedback) 2. Script the conversation using SBI framework 3. Identify if the rule itself needs to be revisited (sometimes the rule is the problem) 4. Define a clear follow-up mechanism

Retrospective-to-ground-rules conversion My team's retrospective produced these "improvements" items: [paste the improve/stop items from the retro] Help me convert these into clear, actionable ground rules that: 1. Are stated positively (what TO do, not what to avoid) 2. Are specific and observable (can you tell if someone follows it or not?) 3. Have an owner or enforcement mechanism 4. Are realistic for this team Also flag any items that are NOT suitable as team ground rules and should be addressed differently (e.g., structural issues, tooling problems, leadership decisions).

Jira / Confluence Template

Confluence — Team Working Agreement

── CONFLUENCE: TEAM WORKING AGREEMENT ─────────────────── Team: [Project Alpha — Full Team] Created: [YYYY-MM-DD] | Next review: [Sprint 10 retro] Process: Co-created in team workshop — 100% team input ── HOW WE WORK ─────────────────────────────────────────── Standups: Daily 09:30 SGT — max 15 min. If blocked, say so clearly. Decisions: Try to decide at team level. Escalate within 24h if stuck. Code review: Review PRs within 1 business day. Comments are about code, not the person. Estimates: No lone wolf estimates. Planning Poker for stories >1 SP. Scope: No self-authorized scope additions. Discuss with PO first. ── HOW WE COMMUNICATE ──────────────────────────────────── Conflicts: Raise concerns directly to the person first. Then PM if unresolved. Feedback: Timely, specific, and given with positive intent. Mistakes: Own them early. No blame culture. ── HOW WE PROTECT QUALITY ──────────────────────────────── DoD must be met before marking a story Done. No exceptions without PM approval. Reviews from customers are welcome — we build for them, not for ourselves.

Define Team Ground Rules