Scrum Master Hub Việt Nam

Scrum Master Hub Việt Nam Cộng đồng Scrum Master VN 🌟 Chia sẻ kinh nghiệm, công cụ Agile & Scrum. Tham gia tại scrummaster.vn!

Mình nhớ hồi mới nhận vai Scrum Master, nhìn quanh phòng Sprint Planning và nhận ra mình là người trẻ nhất trong số nhữn...
31/05/2026

Mình nhớ hồi mới nhận vai Scrum Master, nhìn quanh phòng Sprint Planning và nhận ra mình là người trẻ nhất trong số những người ngồi đó.

Senior dev đã code từ trước khi mình tốt nghiệp. Tech Lead có kinh nghiệm gấp đôi số năm mình đi làm. Và team đã gắn kết với nhau từ trước khi mình đến.

Không có chỗ để "làm quen từ từ."

Những gì thực sự giúp mình được team công nhận không phải là cố gắng chứng minh hay giải thích nhiều hơn. Mà là:

▸ Giữ hình ảnh chuyên nghiệp nhất quán từ buổi đầu tiên
▸ Nâng tiêu chuẩn output, nói chuyện bằng data thay vì cảm tính
▸ Tổ chức đào tạo nội bộ, tạo ngôn ngữ chung với team
▸ Hỗ trợ bằng sự chân thành, không phải sự nhiệt tình thái quá
▸ Tham gia vào văn hóa team thay vì đứng ngoài quan sát

─────────────────────

Scrum Master không có positional authority. Nhưng trust được xây từ từng buổi họp được chuẩn bị kỹ, từng con số được trình bày rõ ràng, từng lần bạn thực sự lắng nghe trước khi kết luận.

Thứ authority đó bền hơn bất kỳ chức danh nào.

Bạn đang ở giai đoạn nào trong hành trình SM? Lúc mới nhận vai, tình huống khó nhất bạn gặp là gì?

📖 Bài đầy đủ, link trong comment đầu tiên 👇

Cuối một buổi Sprint Planning, hai dev cãi nhau về cách implement.Mình nhảy vào ngay: "Thôi thảo luận sau, tiếp tục Plan...
23/05/2026

Cuối một buổi Sprint Planning, hai dev cãi nhau về cách implement.
Mình nhảy vào ngay: "Thôi thảo luận sau, tiếp tục Planning trước đi."

Mình nghĩ mình đã xử lý được conflict.

Thực ra mình vừa gửi tín hiệu ngầm đến cả team: conflict không được phép xảy ra ở đây.

───────────────────────
4 sai lầm SM hay mắc khi xử lý conflict trong team:

✦ Nhảy vào quá sớm, trước khi team có cơ hội tự giải quyết
✦ Để conflict âm ỉ quá lâu, không nhận ra khi nó đã vượt ranh giới
✦ Ra phán quyết thay vì facilitate, người thua không nói nhưng sẽ không hợp tác
✦ Không nhận ra khi chính mình là một bên trong conflict
───────────────────────

Cả bốn lỗi này mình đã từng mắc, ở KiotViet, Viettel Digital, One Mount.
Mỗi lần nhận ra đều là sau khi đã có damage rồi.

Bạn thấy mình hay mắc cái nào nhất?

📖 Đọc bài đầy đủ — link trong comment đầu tiên 👇

Thi PSM I - 85% là ngưỡng pass. Không phải "gần đủ", mà là bắt buộc.Nhiều bạn hỏi mình: "Cần chuẩn bị bao lâu?" Mình thư...
17/05/2026

Thi PSM I - 85% là ngưỡng pass. Không phải "gần đủ", mà là bắt buộc.
Nhiều bạn hỏi mình: "Cần chuẩn bị bao lâu?" Mình thường hỏi ngược lại: "Bạn có bao nhiêu giờ mỗi ngày?"
2 tuần là đủ, nếu ôn đúng cách.
Mình đã thấy người chuẩn bị 1 tháng nhưng fail, và người ôn 10 ngày đạt 93%+. Khác biệt không phải ở thời gian, mà ở cách ôn.
──────────────────────
Những thứ cần, và không cần:
✦ Cần: Scrum Guide 2020, đọc 3 lần, không skim
✦ Cần: Scrum.org Open Assessments, làm đến khi 100% liên tiếp
✦ Cần: Mock exam scenario-based, timed, 60 phút / 80 câu
✦ Không cần: book dày, video series 10 tiếng, 50-tips blogs
──────────────────────
Bẫy hay gặp nhất?
▸ Học theo cách đang practice, không theo Scrum Guide, đây là bẫy của người có kinh nghiệm thực tế
▸ Chỉ làm Open Assessment, bỏ qua scenario-based, đề thật ra nhiều loại này hơn bạn nghĩ
▸ Đọc nhiều nguồn rồi bị confuse terminology, khi có conflict, Scrum Guide luôn thắng
Bạn đang ôn PSM I không? Đang stuck ở phần nào?
📖 Kế hoạch 14 ngày chi tiết, link trong comment đầu tiên 👇

Nhiều bạn SM hỏi mình: "Muốn lên Senior thì cần gì ngoài PSM I?"Câu trả lời thật ra không đơn giản - vì tại Việt Nam, lộ...
14/05/2026

Nhiều bạn SM hỏi mình: "Muốn lên Senior thì cần gì ngoài PSM I?"
Câu trả lời thật ra không đơn giản - vì tại Việt Nam, lộ trình Senior SM vẫn còn khá mờ. Không có career ladder rõ ràng. JD thì mỗi công ty hiểu một kiểu.
───────────────────────
Nhưng sau 7+ năm trong môi trường Agile, mình thấy có một số pattern khá nhất quán:
✦ Năm 0-1: Chạy đúng Scrum events, học cách không làm thay cho team
✦ Năm 1-3: Support 2 teams, coach được PO, đọc được retrospective pattern
✦ Năm 3-5: Giải quyết cross-team dependency, có tiếng nói với leadership
✦ Năm 5+: Drive Agile adoption ở cấp tổ chức, coaching thay vì facilitating
───────────────────────
Điều mình thấy nhiều bạn nhầm nhất: nghĩ rằng Senior = lấy thêm cert hoặc chạy thêm team.
Thực ra, người Senior là người mà team tự vận hành tốt hơn vì có họ ở đó, không phải người làm thay team nhiều hơn.
───────────────────────
Trong bài mình cũng chia sẻ 3 con đường từ Senior SM (Agile Coach, Product, Engineering Manager), checklist tự đánh giá 6 tiêu chí, và góc nhìn về việc nên lấy cert gì ở giai đoạn này dựa trên kinh nghiệm thực tế tại KiotViet, Viettel Digital và One Mount.
Bạn đang ở cột mốc nào? Và điều gì đang block bạn nhiều nhất hiện tại? 👇
📖 Đọc bài đầy đủ — link trong comment đầu tiên 👇

Sprint Planning của team bạn thường mất bao nhiêu tiếng?Nếu câu trả lời là "3-4 tiếng, đôi khi hơn" — đây là kỹ thuật đá...
02/05/2026

Sprint Planning của team bạn thường mất bao nhiêu tiếng?
Nếu câu trả lời là "3-4 tiếng, đôi khi hơn" — đây là kỹ thuật đáng thử.
───────────────────
Planning Poker là cách estimate mà tất cả mọi người đưa ra con số cùng lúc — trước khi thấy của nhau.
Nghe đơn giản, nhưng nó giải quyết một vấn đề rất cụ thể: khi một người (thường là TL hoặc SM) nói con số trước, gần như chắc chắn mọi người sẽ estimate theo — dù họ nghĩ khác. Đây gọi là anchoring bias.
───────────────────
Tại KiotViet, sau khi áp dụng Planning Poker kết hợp Refinement đúng chuẩn:
✦ Sprint Planning giảm từ 4-5 tiếng xuống còn dưới 2 tiếng
✦ Ít "surprise" giữa Sprint hơn
✦ Team chủ động raise risk sớm hơn
Chìa khóa không chỉ là kỹ thuật — mà là dùng nó đúng chỗ: trong Refinement, không phải trong Planning.
───────────────────
Bài viết mới chia sẻ cách tổ chức buổi Planning Poker thực tế, những lỗi phổ biến nhất và cách fix từng cái.
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Team bạn đang estimate như thế nào hiện tại? Đã thử Planning Poker chưa? 👇

"Mình nên thi PSM I hay PSPO I trước?"Câu hỏi này mình nhận được rất nhiều — và câu trả lời không phải "cái nào cũng đượ...
26/04/2026

"Mình nên thi PSM I hay PSPO I trước?"
Câu hỏi này mình nhận được rất nhiều — và câu trả lời không phải "cái nào cũng được".
───────────────────
Hai chứng chỉ này kiểm tra hai góc nhìn khác nhau về Scrum:
▸ PSM I — how: làm thế nào để team làm việc hiệu quả
▸ PSPO I — what & why: xây dựng cái gì, tại sao nó có giá trị
Nhưng có một điều ít ai biết:
80% nội dung ôn tập của PSM I và PSPO I là trùng nhau.
Vì Product Owner là một role trong Scrum — nên muốn thi PSPO I, bạn phải hiểu toàn bộ Scrum framework trước. Nếu bạn đã ôn PSM I kỹ, bạn đã chuẩn bị được 80% cho PSPO I rồi.
───────────────────
Vậy nên thi cái nào trước?
✦ Đang làm SM hoặc dev trong Scrum team → PSM I trước
✦ Đang làm PO, BA, hoặc product → PSM I vẫn là nền tảng tốt hơn để bắt đầu
✦ Chưa chắc → PSM I, vì đây là nền tảng bắt buộc dù bạn theo hướng nào
───────────────────
Bài viết mới so sánh chi tiết hai chứng chỉ — độ khó thực tế, chi phí, và lộ trình mình khuyên.
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Bạn đã thi PSM I hoặc PSPO I chưa? Thi cái nào trước và cảm thấy thế nào? Comment chia sẻ mình nghe với! 👇

"Mình đang làm Scrum Master — nhưng team cũng có Team Lead. Thực ra ai làm gì?"Câu hỏi này mình nghe rất nhiều. Và câu t...
18/04/2026

"Mình đang làm Scrum Master — nhưng team cũng có Team Lead. Thực ra ai làm gì?"
Câu hỏi này mình nghe rất nhiều. Và câu trả lời không đơn giản như trong sách giáo khoa.
───────────────────
Hai role này phục vụ mục đích khác nhau:
▸ SM sở hữu "how we work together" — quy trình, tâm lý an toàn, Agile mindset
▸ Team Lead sở hữu "how we build things" — kỹ thuật, chất lượng code, architecture
Nghe có vẻ rõ ràng. Nhưng thực tế thì không.
───────────────────
3 vùng xám thường gây xung đột nhất mình hay gặp:
✦ Ai quyết định cách làm việc của team?
✦ Ai đại diện team trước stakeholders?
✦ Ai xử lý conflict khi hai người không đồng ý trước mặt team?
Và tình huống khó nhất: khi một người kiêm cả hai role — tech lead vừa là người review code vừa là người facilitate Retro. Team sẽ nói thật đến đâu?
───────────────────
Bài viết mới chia sẻ nguyên tắc phân chia vai trò và cách hai role này phối hợp hiệu quả — từ kinh nghiệm thực tế tại KiotViet và Viettel Digital.
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Team bạn có cả SM lẫn Team Lead không? Hai người phối hợp như thế nào? Comment chia sẻ mình nghe với! 👇

70-80% action items từ Retrospective không bao giờ được thực hiện.Nếu bạn đã từng ngồi trong một buổi Retro, đồng ý với ...
11/04/2026

70-80% action items từ Retrospective không bao giờ được thực hiện.
Nếu bạn đã từng ngồi trong một buổi Retro, đồng ý với action items, rồi Sprint sau nhìn lại thấy không ai làm gì cả — bạn không đơn độc.
Đây không phải lỗi của team. Đây là vấn đề cấu trúc.
───────────────────
4 nguyên nhân thực tế mình hay gặp nhất:
▸ Action items quá mơ hồ — "Cải thiện giao tiếp" không phải action item, đó là ước muốn
▸ Không ai cụ thể nhận làm — "cả team cùng làm" = không ai làm
▸ Action items không được đưa vào Sprint Backlog — không thấy thì không làm
▸ Không review action items cũ trước khi bắt đầu Retro mới
───────────────────
Bài viết mới chia sẻ:
✦ Framework CAT để viết action items đúng chuẩn (Concrete, Attainable, Timely)
✦ Who-What-When Matrix để ai cũng biết mình chịu trách nhiệm gì
✦ Flow Retrospective 60-90 phút mình đang dùng thực tế
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Retro của team bạn thường kết thúc như thế nào? Có action items không — và Sprint sau bạn có làm không? 👇

Daily Scrum của team bạn thường mất bao lâu?Nếu câu trả lời là "hơn 20 phút" — đây là điều mình muốn chia sẻ.───────────...
04/04/2026

Daily Scrum của team bạn thường mất bao lâu?
Nếu câu trả lời là "hơn 20 phút" — đây là điều mình muốn chia sẻ.
───────────────────
15 phút không phải con số ngẫu nhiên. Khi Daily kéo dài hơn, thường không phải vì team nói nhiều — mà vì đang làm sai mục đích của buổi họp.
4 nguyên nhân mình hay gặp nhất qua các team ở KiotViet, Viettel Digital và One Mount:
▸ Daily thành buổi báo cáo một chiều cho Manager
▸ Không có Sprint Goal rõ ràng để team bám vào
▸ Thảo luận kỹ thuật bị kéo vào giữa buổi họp
▸ Không có timebox hiển thị — team tự giãn ra lấp đầy thời gian
───────────────────
Bài viết mới chia sẻ cách fix từng nguyên nhân, kèm format 15 phút thực tế mình đang dùng — có thể áp dụng ngay từ buổi Daily tiếp theo.
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Daily Scrum của team bạn đang gặp nguyên nhân nào? Comment chia sẻ mình nghe với! 👇

Người có kinh nghiệm Scrum thực tế đôi khi thi PSM I lại khó hơn người mới.Nghe lạ — nhưng đây là lý do thực tế.────────...
28/03/2026

Người có kinh nghiệm Scrum thực tế đôi khi thi PSM I lại khó hơn người mới.
Nghe lạ — nhưng đây là lý do thực tế.
───────────────────
Bài thi PSM I hỏi về Scrum trong bối cảnh lý tưởng theo Scrum Guide.
Nhưng Scrum đang được triển khai ở Việt Nam phần lớn chưa đúng chuẩn — Daily Scrum thành buổi báo cáo, SM bị nhầm thành PM, Sprint Planning chỉ là buổi giao việc...
Nếu bạn làm việc trong môi trường đó đủ lâu, cách triển khai sai đó trở thành "bình thường" trong đầu. Và khi vào phòng thi, bạn sẽ trả lời theo kinh nghiệm thực tế — thay vì theo Scrum Guide.
Đó là lúc người có 3 năm kinh nghiệm thi trượt, còn người mới học 2 tuần lại đậu.
───────────────────
Mình đã thi và đạt trên 90% lần đầu. Bài viết mới chia sẻ:
✦ Cái bẫy lớn nhất cho người có kinh nghiệm thực tế
✦ Lộ trình ôn thi thực tế từ 0 đến sẵn sàng
✦ Cách xử lý khi 2 đáp án đều có vẻ đúng
📖 Đọc bài đầy đủ — link trong comment đầu tiên bên dưới 👇
───────────────────
Bạn đã thi PSM I chưa? Phần nào bạn thấy khó nhất? 👇

Address

Hanoi
10000

Alerts

Be the first to know and let us send you an email when Scrum Master Hub Việt Nam posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Share