T10: Shared Understanding | Domain 1

📖 Lý thuyết / Theory

🇺🇸 English

Shared understanding means all parties have the same mental model of what the project is, what success looks like, and how work will be done. Without it, teams waste effort on assumptions, rework accumulates, and stakeholders become disappointed.

Tools for shared understanding:

Project Charter: High-level authorization and shared vision
Definition of Done (DoD): Agile — team's shared quality standard
Definition of Ready (DoR): What "ready to develop" means
User Stories: "As a [user], I want [feature] so that [benefit]"
Kickoff meetings: Formal alignment session at project/sprint start

Reference: PMI — Shared Understanding

🇻🇳 Tiếng Việt

Sự hiểu biết chung nghĩa là tất cả các bên có cùng mô hình tư duy về dự án là gì, thành công trông như thế nào, và công việc sẽ được thực hiện như thế nào. Không có nó, các teams lãng phí effort vào giả định, rework tích lũy và stakeholders thất vọng.

🔧 Definition of Done (DoD) Template

Definition of Done — Project Alpha Backend

A user story is DONE when ALL of the following are true: Code Quality ✓ Code reviewed by ≥2 team members (including Tech Lead for architecture changes) ✓ All automated tests passing (unit + integration) ✓ Test coverage ≥80% for new code ✓ No critical SonarQube violations ✓ Code follows project Go standards (golangci-lint clean) Functionality ✓ Acceptance criteria met and verified by QA ✓ Edge cases tested (null inputs, boundary values, error states) ✓ API contract validated against OpenAPI spec ✓ Business logic reviewed with Product Owner Documentation ✓ API documentation updated in Swagger/OpenAPI ✓ ADR created for architectural decisions ✓ README updated if new service/module created Deployment ✓ Feature deployed to staging environment ✓ Smoke tests passing on staging ✓ No regression in existing features (regression suite green) ✓ Monitoring alerts configured for new endpoints

💼 Thực chiến / Scenario

🏢

FinTech Company X — Alignment on "Done" across Teams

Tình huống: Project Alpha sprint 2 kết thúc. Dev team nói feature "done". QA team nói chưa done — test environment chưa được deploy. Business stakeholder nói chưa done — acceptance criteria chưa verified với business.

Root cause: Thiếu shared understanding về "What does done mean?"

Solution: PM tổ chức DoD workshop với toàn team (devs, QA, PO, BA). Cùng nhau define và agree trên DoD checklist. Post DoD ở Confluence và reference trong mỗi PR template. Sprint 3 trở đi: không có story nào được marked done nếu chưa qua hết DoD checklist.

PMP lesson: Shared understanding không tự nhiên xuất hiện — PM phải chủ động tạo ra nó thông qua facilitated workshops và documented agreements.

✏️ Practice Questions

Question 1

The development team believes a feature is complete, but the business stakeholder says it doesn't meet expectations. This situation is MOST LIKELY caused by:

A. Poor development quality
B. Lack of shared understanding of acceptance criteria at the start of the sprint
C. Inadequate testing by the QA team
D. Scope creep introduced by the stakeholder

✅ Answer: B — This is a classic "definition of done" / shared understanding issue. When development and business have different expectations, it usually points to misaligned requirements or acceptance criteria. The solution is to involve stakeholders in defining acceptance criteria BEFORE work begins, not after. This is also a quality management issue (prevention) — validate requirements upfront.

Question 2

A team is starting a new project and members have different interpretations of what 'done' means for user stories. What is the BEST tool to address this?

A. A detailed project schedule
B. A shared Definition of Done agreed by the whole team
C. Individual task assignments
D. A risk register

✅ Answer: B — A Definition of Done (DoD) creates a single, explicit, shared understanding of what 'complete' means for every user story. Without it, each team member applies their own standard, leading to inconsistent quality and rework. A project schedule (A) manages time, not quality criteria. A risk register (D) tracks uncertainties, not completion standards.

Question 3

Mid-sprint, a developer says their task is 'done' but it has no unit tests and hasn't been reviewed. The team's DoD requires both. What should the Scrum Master/PM do?

A. Accept it since the core functionality works
B. Enforce the DoD — the item is not done until all DoD criteria are met; move it back to in-progress
C. Remove the test requirement from the DoD to unblock the sprint
D. Ask the developer to add tests in the next sprint

✅ Answer: B — The DoD is a non-negotiable quality standard. 'Done' means ALL criteria are met, not just the functional part. Accepting incomplete work (A, D) accumulates technical debt and erodes the DoD's meaning. Weakening the DoD mid-sprint (C) sends the wrong signal to the team and lowers the quality bar permanently. The item must go back to in-progress.

🤖 AI Tools for PMs

🤖

How AI Augments This Process

AI helps PMs draft project charters, create shared glossaries, synthesize diverse stakeholder inputs into a coherent project vision, and write purpose statements that align teams.

Sample Claude Prompts

Project charter drafting Help me draft a Project Charter for approval. Project name: [name] Problem/opportunity: [what business problem does this solve?] Proposed solution: [high-level description of the project deliverable] Business case: [why this is worth doing — ROI, risk reduction, strategic fit] Scope (in scope): [what the project will deliver] Scope (out of scope): [what it explicitly will NOT include] Key stakeholders: [sponsor, customers, teams affected] High-level timeline: [target start, key milestones, end date] Budget estimate: [range] Key risks: [top 3] Assumptions: [major assumptions the project rests on] Constraints: [fixed factors — date, budget, regulatory] Draft a Project Charter that is concise (1-2 pages), gets sponsor approval, and creates shared understanding across all stakeholders.

Project glossary creation My project has specialized terms that mean different things to different stakeholders. Help me build a project glossary. Project domain: [fintech / healthcare / logistics / etc.] Stakeholder groups: [technical team / business / external partners / regulators] Known confusion points: [terms that have caused misunderstandings — list them] Key acronyms used: [list] Create a project glossary with: 1. Term, definition (plain language), how it's used in our project context 2. Flag terms that mean different things to different groups (disambiguation entries) 3. Acronym expansion list 4. Terms to avoid (jargon that should be replaced with plain language) Format for Confluence.

Project purpose/vision statement My team lacks a clear, memorable purpose statement — people can't explain why we're doing this project. Project facts: What we're building: [description] Who benefits: [customers / users / org] What problem we solve: [current pain] What changes after we deliver: [future state] Business goal: [revenue / cost / risk / compliance] Write 3 versions of a project purpose statement (1-2 sentences each): 1. Executive version (strategic, outcome-focused) 2. Team version (motivating, meaningful work) 3. Customer/user version (benefit-focused) The best one should pass the "elevator pitch" test: a team member can explain the project to a stranger in 30 seconds.

Jira / Confluence Template

Confluence — Project Glossary

── CONFLUENCE: PROJECT GLOSSARY ───────────────────────── Project: [Project Alpha] | Maintained by: [PM] | Last updated: [date] Purpose: Single source of truth for project terminology across all teams ── TERMS ───────────────────────────────────────────────── Loan Application Definition: A formal request submitted by a borrower to initiate credit evaluation In context: In Project Alpha, refers to the digital form submitted via mobile app Owned by: Product team | Approved by: Business Analyst Credit Engine Definition: The automated system that calculates creditworthiness scores In context: Refers specifically to the AI/ML scoring module in the backend Note: ≠ Credit Bureau (external data source) Go-Live Definition: The moment the system becomes available to end users in production In context: Project Alpha Go-Live = Branch rollout phase 1 (5 branches) Note: ≠ UAT completion (internal) ≠ Full launch (all 20 branches) ── ACRONYMS ────────────────────────────────────────────── PH = Philippines | UAT = User Acceptance Testing | CCB = Change Control Board

Build Shared Understanding