PSM I Study
Scrum Guide 2020 · PSM I

Ôn tập PSM I hiệu quả, có hệ thống

Tổng hợp đầy đủ kiến thức Professional Scrum Master I theo Scrum Guide 2020: lý thuyết, vai trò SM, glossary, flashcards và 120+ câu quiz tương tác kèm giải thích.

60'Thời gian thi
80Câu hỏi
85%Điểm đạt
$200Lệ phí thi

3 Trụ cột thực nghiệm

1
Transparency

Sự minh bạch

2
Inspection

Sự kiểm tra

3
Adaptation

Sự thích ứng


5 Giá trị Scrum (F-O-R-C-C)

FocusOpennessRespectCommitmentCourage

Học thuyết Scrum

Scrum dựa trên empirical process control (empiricism) và lean thinking. Scrum là framework, không phải methodology/process.

🔍 TransparencySự minh bạch

Significant aspects của process phải visible với những người chịu trách nhiệm về outcome. Là tiền đề của Inspection — không minh bạch thì kiểm tra sẽ sai.

🧪 InspectionSự kiểm tra

Artifacts và tiến độ phải được kiểm tra thường xuyên để phát hiện variances. Scrum có 5 events như feedback loops. Là tiền đề của Adaptation.

🔄 AdaptationSự thích ứng

Khi process lệch khỏi giới hạn, phải điều chỉnh càng sớm càng tốt. Khó thực hiện khi thiếu self-management và empowerment.

5 Giá trị Scrum (F-O-R-C-C)

FocusTập trung
OpennessCởi mở
RespectTôn trọng
CommitmentCam kết
CourageCan đảm

Scrum Team được thiết kế để tối ưu (F-C-P)

FlexibilityLinh hoạt
CreativitySáng tạo
ProductivityNăng suất
💡 Ghi nhớ: Khi 5 giá trị được thể hiện → 3 trụ cột come to lifebuild trust. Scrum artifacts: P-S-I (Product Backlog, Sprint Backlog, Increment). Scrum pillars: T-I-A.

Scrum Team

3 accountabilities: PO + SM + Developers. 10 người hoặc ít hơn. Không sub-teams, không hierarchies, không titles. Self-managing + Cross-functional.

👑 Product Owner

Tối đa hoá giá trị sản phẩm.

  • 1 người, never a committee/PMO
  • Quản lý Product Backlog (ordering, visibility, understanding)
  • Có quyền huỷ Sprint (chỉ PO)
  • Quyết định khi nào release
  • Có thể delegate nhưng vẫn accountable
  • Đo performance: customer satisfaction, revenue — KHÔNG phải velocity
🧭 Scrum Master

Triển khai Scrum, đảm bảo hiệu quả của Team.

  • True leader who serves (servant-leadership)
  • Manage the process, not people
  • Promote & support Scrum adoption
  • Remove impediments
  • Ensure events đúng timebox
  • Increase transparency of artifacts
  • 1 SM có thể manage multiple teams
🛠 Developers

Tạo ra Increment khả dụng mỗi Sprint.

  • Self-organizing: không ai chỉ cách làm
  • Cross-functional: có đủ skills
  • Quản lý Sprint Backlog
  • Estimate effort/size
  • Đo Sprint performance
  • Quyết định technical approach
  • Không có titles — tất cả là "Developers"
⚠️ Scaled Scrum: n teams → 1 Product Backlog, 1 PO, n Sprint Backlogs, 1 integrated Increment, n SM (có thể ít người hơn n). DoD phải compatible với nhau.

Các sự kiện Scrum

Sprint là container. Mỗi event là feedback loop (formal opportunity to inspect & adapt). Không có Sprint Zero, Hardening Sprint, Release Sprint.

≤ 1 tháng (fixed)

🏃 Sprint

Nhịp tim Scrum. Duration fixed, không thể rút ngắn/kéo dài khi đã bắt đầu. Sprint mới bắt đầu ngay sau Sprint trước (no gaps).

  • Sprint Goal can't be changed (trừ khi PO cancel Sprint)
  • Scope có thể re-negotiate với PO
  • Quality goals không giảm

Cancel Sprint: Chỉ PO. Incomplete PBIs → re-estimate → về Product Backlog.

≤ 8 giờ

📅 Sprint Planning

Toàn bộ Scrum Team + có thể mời stakeholders.

  • Why — Sprint Goal (cả Scrum Team craft)
  • What — Developers forecast PBIs
  • How — Plan work items ≤ 1 ngày

Input: Product Backlog (prioritized), latest Increment, projected capacity, past performance.

15 phút

☀️ Daily Scrum

Sự kiện cho Developers. Cùng giờ, cùng địa điểm. Developers participate (talk); others attend (watch only).

Lưu ý: PO can attend nhưng cannot participate (trừ khi đang làm Sprint Backlog item).

≤ 4 giờ

🎯 Sprint Review

Informal meeting. Scrum Team + stakeholders collaborate. Là buổi làm việc.

Output: Inspected Increment + Revised Product Backlog cho Sprint tiếp.

2 events có stakeholders: Sprint Review + Sprint Planning.

≤ 3 giờ

🔁 Sprint Retrospective

Kết thúc Sprint. Inspect: people, relationships, process, tools. Create improvement plan. Improvements có thể vào Sprint Backlog kế tiếp.

Toàn bộ Scrum Team tham gia (PO cũng tham gia as Scrum Team member).

⏱ Timebox (Sprint 1 tháng): Planning ≤ 8h · Daily 15' · Review ≤ 4h · Retro ≤ 3h. Sprint ngắn hơn → events ngắn hơn.

Tạo phẩm Scrum (P-S-I) & Commitments

3 artifacts + 3 commitments. Tạo phẩm có transparency thấp → quyết định sai → giảm value, tăng risk.

📋 Product Backlog

Owned & managed by PO. Never complete, dynamic, emergent. Single source of work. Attributes: description, order, estimate, value.

Refinement: ongoing activity, ≤ 10% capacity Developers. Top items nhỏ & rõ, bottom items lớn & mờ.

Commitment: 🎯 Product Goal — future state of product, long-term objective. Hoàn thành/từ bỏ trước khi chọn mục tiêu mới.
📝 Sprint Backlog

Owned & managed by Developers. = Sprint Goal (why) + PBIs (what) + Plan (how). Cập nhật throughout Sprint. Items deemed unnecessary → removed.

Commitment: 🎯 Sprint Goal — mục tiêu duy nhất. Cả Scrum Team craft tại Sprint Planning. CANNOT change during Sprint.
📦 Increment

Potentially releasable. Phải usable. Nhiều Increments/Sprint. Chỉ Developers tạo Increment. Có thể release bất kỳ lúc nào.

Commitment: 🎯 Definition of Done — shared understanding. Tăng transparency. Giúp Developers forecast. Có thể improve (tại Retro), nhưng KHÔNG đổi giữa Sprint.
💡 DoD quan trọng: DoD do Scrum Team tạo (nếu org không có standard). Multiple teams cùng product → DoD phải compatible. PBI không đạt DoD → không release, quay về PB.

Trọng tâm Scrum Master

Phần kiến thức mở rộng quan trọng cho kỳ thi PSM I.

🧭 SM serves Scrum Team

  • Coaching self-management & cross-functionality
  • Helping focus on high-value Increments meeting DoD
  • Causing removal of impediments
  • Ensuring events take place, positive, productive, within timebox

👑 SM serves Product Owner

  • Finding techniques for effective PB management
  • Helping Team understand clear & concise PBIs
  • Helping establish empirical product planning
  • Facilitating stakeholder collaboration
  • Ensuring PO knows how to arrange PB to maximize value

🏢 SM serves Organization

  • Leading, training, coaching Scrum adoption
  • Planning & advising Scrum implementations
  • Helping understand empirical approach for complex work
  • Removing barriers between stakeholders & Scrum Teams

🔍 SM detects incomplete transparency

  • Inspecting artifacts
  • Sensing patterns
  • Listening closely to what is being said
  • Detecting differences between expected vs real results

SM copes with incomplete transparency via: learning, convincing, change.

🚫 SM KHÔNG làm gì?

  • Không manage people (manage process)
  • Không assign tasks cho Developers
  • Không prescribe solutions — coach/facilitate
  • Không đồng ý/không đồng ý opinions
  • Scenario answer: coaching, mentoring, teaching, facilitating, supporting self-problem solving

📋 SM scenario responses

Khi có vấn đề, đáp án đúng thường là:

  • Ask Developer to share issue with Team
  • Coach team to self-organize and solve
  • Facilitate discussion
  • Teach Scrum principles

Đáp án sai: SM tự giải quyết, assign, agree/disagree, prescribe.

Exam Tips & Traps

Những lưu ý quan trọng từ ScrumPass Study Notes.

⚠️ Incompatible with Scrum

  • Project Manager / Product Manager roles
  • Sprint Zero, Hardening Sprint, Release Sprint
  • Baselines
  • SM/PO ordering people (servant leadership)
  • Titles trong Developers (tester, architect...)
  • Definition of Ready (không accepted bởi Scrum.org)

📝 Attend vs Participate

Attend = observe, watch → TRUE cho PO tại Daily Scrum.

Participate = engage, talk → FALSE cho PO tại Daily Scrum (trừ khi đang làm Sprint Backlog item).

Một từ thay đổi tất cả!

🔤 Can vs Should

"can" = may (được phép) → thường TRUE

"should" = ought to, required → thường FALSE nếu không bắt buộc

Ví dụ: "PO can attend Daily" ✅ vs "PO should attend Daily" ❌

🔢 Question Types

  • Multiple Choice: ~65%
  • Multiple Response: ~30%
  • True/False: ~5%

Tìm BEST answer, không phải right answer. Chú ý từ "NOT", "EXCEPT".

📊 Performance đo bằng gì?

PO đo product performance: customer satisfaction, stakeholder engagement, revenue.

KHÔNG bao giờ đo bằng: velocity, burn-down, team collaboration, individual performance.

Developers đo Sprint performance (Daily Scrum, Sprint Backlog tracking).

🏗 Tuckman's Model

Khi thêm/bớt người → productivity giảm short-term. Team phải qua lại Forming → Storming → Norming → Performing.

Developers members có thể thay đổi giữa Sprint nhưng sẽ có short time reduction in productivity.

Glossary — Thuật ngữ Scrum

Flashcards

Click vào thẻ để lật. Dùng phím ← → để chuyển thẻ.

Click để lật
1 / 1

Quiz luyện thi PSM I

120+ câu hỏi mô phỏng đề thi, có giải thích đáp án.

Chọn chế độ ôn tập