Mở đầu — vì sao bài này quan trọng
Hãy hình dung một cảnh quen thuộc: đội của bạn vừa kết thúc Sprint Planning. Mọi người gật gù, backlog đã được kéo vào Sprint, Sprint Goal đã viết lên bảng. Ai cũng tự tin. Rồi đến ngày thứ tám của Sprint, một dependency với team Backend chưa sẵn sàng, một thành viên xin nghỉ phép đột xuất, và một story tưởng nhỏ hóa ra đụng vào hệ thống thanh toán cũ kỹ không ai dám sửa. Sprint trượt. Trong Retrospective cuối Sprint, ai đó buột miệng: "Thật ra cái rủi ro này em đã linh cảm ngay từ đầu rồi…".
Câu nói "em đã linh cảm ngay từ đầu" chính là vấn đề mà bài học hôm nay muốn giải quyết. Trong rất nhiều đội Scrum, các rủi ro không phải là điều bất ngờ từ trên trời rơi xuống — chúng đã ở đó, nằm im trong đầu một vài người, nhưng không có một không gian an toàn và có cấu trúc nào để được nói ra trước khi quá muộn. Pre-mortem là công cụ giúp bạn mở đúng cái không gian đó.
Khác với Retrospective (nhìn lại sau khi Sprint kết thúc) hay Premortem cấp dự án lớn (mà bài 40 đã đề cập), bài này tập trung vào một phiên bản rất gọn, rất thực dụng: Pre-mortem nhúng thẳng vào Sprint Planning, gói trong 15 phút. Nó không thay thế việc lập kế hoạch, mà là một lớp kiểm tra rủi ro nhanh ngay trước khi đội cam kết. Với vai trò Scrum Master, đây là một trong những công cụ "rẻ tiền nhất nhưng lời nhất" mà bạn có thể đưa vào toolbox của mình: chi phí 15 phút, nhưng có thể cứu cả một Sprint.
Khái niệm cốt lõi
Pre-mortem là gì?
Pre-mortem (tạm dịch: "khám nghiệm trước") là một kỹ thuật quản trị rủi ro do nhà tâm lý học Gary Klein đề xuất. Ý tưởng gốc rất táo bạo về mặt tâm lý: thay vì hỏi "Có rủi ro gì có thể xảy ra?", ta tua nhanh thời gian tới cuối Sprint và tuyên bố thẳng: "Sprint này đã thất bại hoàn toàn. Hãy giải thích vì sao."
Nghe có vẻ chỉ là một thủ thuật chơi chữ, nhưng đằng sau nó là một cơ chế tâm lý đã được nghiên cứu kỹ, gọi là prospective hindsight (nhìn lại từ tương lai). Nghiên cứu của Deborah Mitchell và cộng sự cho thấy khi con người tưởng tượng một sự kiện đã chắc chắn xảy ra rồi mới đi tìm nguyên nhân, khả năng họ nêu ra được lý do chính xác và cụ thể tăng khoảng 30% so với khi chỉ hỏi "điều gì có thể xảy ra". Lý do: bộ não chuyển từ chế độ phán đoán xác suất mơ hồ ("chắc không sao đâu") sang chế độ tường thuật cụ thể ("vì cái X đã hỏng, dẫn tới Y").
Vì sao đội cần điều này — vấn đề tâm lý nhóm
Trong Sprint Planning, có hai lực cản tâm lý khiến rủi ro bị che giấu:
- Áp lực đồng thuận (groupthink): Khi cả phòng đang hào hứng cam kết, người duy nhất nêu lo ngại dễ bị xem là "tiêu cực", "phá đám". Ít ai muốn làm người đó.
- Lạc quan thái quá (optimism bias): Đội thường ước lượng dựa trên kịch bản mọi thứ suôn sẻ, bỏ qua phần "nếu mọi thứ rối ren".
Vị trí trong Sprint Planning
Sprint Planning theo Scrum Guide 2020 trả lời ba câu hỏi (ba "Topic"):
- Topic 1 — Why: Sprint Goal là gì?
- Topic 2 — What: Chọn những Product Backlog Item nào?
- Topic 3 — How: Lập kế hoạch thực hiện như thế nào?
Phân biệt nhanh với các công cụ họ hàng
- Premortem cấp dự án (bài 40): rộng hơn, dài hơn, chạy đầu một dự án/release lớn, có thể 60–90 phút.
- Pre-mortem for Sprint (bài này): phiên bản nén, 15 phút, lặp lại mỗi Sprint, gắn chặt với một Sprint Goal cụ thể.
- Risk-Adjusted Backlog / FMEA: thiên về tính điểm rủi ro định lượng phức tạp — quá nặng cho nhịp Sprint.
- Retrospective: nhìn về quá khứ; Pre-mortem nhìn về tương lai gần.
Tình huống thực tế
Tình huống 1 — Tiki và cái dependency ai cũng "tưởng đã xong"
Một squad sản phẩm tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là squad Checkout) chuẩn bị Sprint hai tuần với Sprint Goal: "Người dùng có thể thanh toán bằng ví điện tử mới X ngay trong luồng đặt hàng". Đội gồm 6 người, kéo vào 21 story point.
Scrum Master dành 12 phút cuối Topic 3 chạy Pre-mortem. Câu hỏi đặt ra: "Hai tuần nữa, demo thất bại, không có gì để demo. Vì sao?". Mỗi người viết im lặng vào sticky note trong 3 phút. Khi gom lại, có một note xuất hiện tới ba lần với nội dung khác nhau nhưng cùng gốc: "API sandbox của ví X chưa bật môi trường test cho team mình".
Hóa ra Product Owner đã "tưởng" bên đối tác cung cấp ví đã mở sandbox, vì có một email từ tuần trước. Nhưng không ai thực sự kiểm tra. Nếu không có Pre-mortem, rủi ro này chỉ lộ ra vào ngày thứ 6 khi lập trình viên bắt đầu code phần tích hợp — mất nửa Sprint.
Diễn giải: Đội ngay lập tức tạo một action: PO gọi điện cho đối tác trong ngày để xác nhận, và đội chuẩn bị một mock service làm phương án dự phòng. Họ cũng giảm cam kết từ 21 xuống 18 điểm để có buffer.
Bài học: Pre-mortem không tạo ra rủi ro mới — nó kéo rủi ro đã âm ỉ ra ánh sáng sớm hơn 5–6 ngày. Khoảng thời gian đó chính là giá trị.
Tình huống 2 — Một startup fintech Singapore và "cái story 1 điểm chết người"
Một startup fintech ở Singapore với đội phân tán (3 người ở Singapore, 2 ở Đà Nẵng) có thói quen bỏ qua Pre-mortem vì "Sprint nào cũng giống nhau". Một Sprint nọ, họ kéo vào một story trông cực kỳ vô hại: "Đổi label nút từ 'Pay' thành 'Confirm Payment'" — ước lượng 1 điểm.
Lần này Scrum Master kiên quyết chạy Pre-mortem 10 phút. Khi đến lượt một dev junior, cô rụt rè viết: "Cái nút đó nằm trong một component dùng chung cho cả app Lending và app Savings, đổi text có thể ảnh hưởng cả phần kiểm thử tự động (automation test) của đội khác". Một lo ngại nhỏ, nhưng đúng.
Diễn giải: Đội quyết định trước khi làm sẽ ping team Savings để xác nhận, và thêm một dòng vào kế hoạch: chạy lại bộ regression test chung. Đúng như dự đoán, có 14 automation test bị hỏng vì so khớp text cứng. Nhờ biết trước, họ xử lý gọn trong nửa ngày thay vì bị một bug production gây rối luồng thanh toán.
Bài học: Rủi ro lớn nhất thường ẩn trong story nhỏ nhất, vì story nhỏ không được ai soi kỹ. Pre-mortem buộc cả những item "hiển nhiên" cũng phải qua một lượt kiểm tra. Và lưu ý cách Scrum Master tạo an toàn để dev junior — người thường im lặng — dám nói.
Tình huống 3 — Đội nội bộ một ngân hàng VN và rủi ro con người
Một đội phát triển core banking tại một ngân hàng ở Hà Nội chạy Pre-mortem trước Sprint cuối quý. Một rủi ro nổi lên không phải về kỹ thuật mà về con người: "Tuần sau là kỳ thi chứng chỉ ngân hàng nội bộ, ba thành viên trong đội phải ôn và đi thi, năng lực thực tế của đội giảm khoảng 40%".
Đây là loại rủi ro mà không một công cụ kỹ thuật nào (DoR, story splitting) bắt được, nhưng Pre-mortem thì có, vì nó hỏi mở "vì sao Sprint thất bại" chứ không chỉ "story này có vấn đề kỹ thuật gì".
Diễn giải: Đội điều chỉnh ngay: giảm 30% khối lượng cam kết, sắp xếp các task quan trọng vào tuần đầu khi đội còn đủ người, và thông báo trước cho stakeholder rằng Sprint này tốc độ sẽ chậm vì lý do chính đáng.
Bài học: Pre-mortem là công cụ rủi ro toàn diện — kỹ thuật, dependency, con người, môi trường. Đừng giới hạn nó vào riêng rủi ro code.
Hướng dẫn từng bước
Đây là quy trình 15 phút chuẩn để chạy Pre-mortem ngay trong Sprint Planning Topic 3. Bạn có thể in nó ra như một "công thức" và dùng lặp lại.
Bước 1 — Stage / Dựng bối cảnh (2 phút)
Scrum Master tuyên bố rõ ràng, dùng đúng thì quá khứ để kích hoạt prospective hindsight:
> "Bây giờ chúng ta tua tới ngày cuối Sprint. Sprint Review đang diễn ra và... chúng ta không có gì để demo. Sprint Goal đã thất bại hoàn toàn. Đây không phải giả thuyết — nó đã xảy ra. Nhiệm vụ của chúng ta trong vài phút tới là giải thích vì sao nó đã thất bại."
Lưu ý ba điều khi dựng bối cảnh: (1) dùng thì quá khứ ("đã thất bại"), (2) khẳng định chắc chắn (không "nếu", không "có thể"), (3) nhấn mạnh đây là nhiệm vụ chung, nêu rủi ro là làm đúng việc, không phải bi quan.
Bước 2 — Generate / Sinh rủi ro độc lập (4 phút)
Mỗi người viết im lặng các lý do thất bại vào sticky note (hoặc Miro/FigJam nếu phân tán) — mỗi lý do một note. Im lặng là then chốt: nó tránh việc người nói đầu tiên định hình suy nghĩ của cả nhóm (anchoring), và cho người hướng nội/junior cơ hội đóng góp ngang bằng.
Gợi ý câu hỏi mồi để dán lên bảng:
- Dependency nào có thể không sẵn sàng?
- Giả định nào của chúng ta có thể sai?
- Ai có thể vắng mặt? Năng lực đội có gì thay đổi?
- Story nào ẩn chứa độ phức tạp ta chưa thấy?
- Điều gì ngoài tầm kiểm soát của đội có thể chen vào?
Bước 3 — Share & Cluster / Chia sẻ và gom nhóm (4 phút)
Lần lượt mỗi người đọc note của mình lên bảng (round-robin, mỗi lượt một note để mọi người đều được nói). Scrum Master gom các note tương tự thành cụm. Thường sẽ có 3–5 cụm rủi ro nổi bật. Không tranh luận đúng/sai ở bước này — chỉ thu thập.
Bước 4 — Prioritize / Ưu tiên (2 phút)
Đội dùng dot voting nhanh: mỗi người 2–3 chấm dán vào cụm rủi ro mà họ thấy vừa khả năng cao vừa tác động lớn. Chỉ chọn ra 2–3 rủi ro hàng đầu để xử lý — đừng cố xử lý hết, sẽ làm loãng và phá vỡ khung thời gian.
Bước 5 — Mitigate / Hành động (3 phút)
Với mỗi rủi ro top, đội quyết một trong các hướng:
- Phòng ngừa (prevent): hành động cụ thể để giảm khả năng xảy ra (vd: gọi xác nhận dependency hôm nay).
- Giảm nhẹ (mitigate): chuẩn bị phương án nếu nó xảy ra (vd: dựng mock service).
- Điều chỉnh cam kết: giảm scope, thêm buffer, sắp xếp lại thứ tự.
- Chấp nhận và theo dõi: ghi nhận, gán người canh chừng.
Lưu ý về timebox và biến thể
- Đội mới làm quen: 15 phút là vừa. Đội thành thục: có thể nén còn 8–10 phút.
- Sprint rủi ro cao (release lớn, nhiều dependency): cho phép giãn tới 20 phút.
- Đội phân tán: dùng bảng số (Miro, FigJam, Mural), giai đoạn viết im lặng giúp cân bằng múi giờ/ngôn ngữ rất tốt.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Pre-mortem thành phiên than vãn. Nếu để mở miệng tự do, nó dễ trượt thành "dự án này lúc nào chẳng trễ". Mẹo: luôn ép câu hỏi về một Sprint Goal cụ thể của Sprint này, và luôn kết bằng action. Không có action thì không phải Pre-mortem, chỉ là kêu ca.
Lỗi 2 — Bỏ giai đoạn viết im lặng. Nếu nhảy thẳng vào thảo luận miệng, người nói to và người cấp cao sẽ chiếm sóng, junior im bặt — đúng những người thường thấy rủi ro tận đáy. Luôn giữ 4 phút viết độc lập.
Lỗi 3 — Cố xử lý mọi rủi ro. Một danh sách 15 rủi ro mà không ưu tiên sẽ làm đội tê liệt hoặc bỏ qua hết. Kỷ luật: chỉ 2–3 rủi ro top mỗi Sprint.
Lỗi 4 — Để Scrum Master trở thành người phán xét rủi ro. Vai trò của bạn là facilitator, không phải người quyết rủi ro nào "đáng kể". Hãy để đội tự vote và tự quyết. Bạn giữ khung thời gian và sự an toàn tâm lý.
Lỗi 5 — Chạy mỗi Sprint một cách máy móc rồi nhàm. Sau vài Sprint, đội có thể thấy "lại Pre-mortem". Mẹo: thỉnh thoảng đổi cách dựng bối cảnh (vd: "Báo chí đưa tin Sprint của chúng ta là thảm họa lớn nhất năm — tiêu đề bài báo là gì?"), hoặc chỉ chạy ở những Sprint thực sự rủi ro cao thay vì mọi Sprint.
Mẹo về an toàn tâm lý: Hãy là người nêu rủi ro đầu tiên, và nêu một rủi ro liên quan đến chính bạn ("Tôi e là tôi sẽ bị kéo sang họp khác và không hỗ trợ đội kịp"). Khi Scrum Master tự phơi bày, mọi người thấy an toàn để làm theo.
Mẹo đo lường giá trị: Lưu lại các rủi ro được nêu trong Pre-mortem, và trong Retro cuối Sprint, đối chiếu xem cái nào đã thực sự xảy ra. Khi đội thấy "ồ, đúng là chúng ta đã đoán trúng và đã chặn được", họ sẽ tin vào công cụ này và không còn xem nó là gánh nặng.
Bài tập thực hành
Bài tập 1 — Tự chạy thử trên giấy (cá nhân, 15 phút). Lấy Sprint hiện tại hoặc gần nhất của đội bạn. Tự viết ra ít nhất 8 lý do "vì sao Sprint này đã thất bại". Phân loại chúng theo 4 nhóm: kỹ thuật, dependency, con người, môi trường. Bạn có phát hiện nhóm nào mình thường bỏ quên không? (Phần lớn Scrum Master quên nhóm "con người".)
Bài tập 2 — Soạn kịch bản facilitation (cá nhân, 20 phút). Viết ra nguyên văn câu "dựng bối cảnh" (Bước 1) bằng tiếng Việt cho đội của bạn, sao cho tự nhiên với văn hóa đội. Viết thêm 5 câu hỏi mồi phù hợp với lĩnh vực sản phẩm của bạn. Chuẩn bị sẵn để dùng ở Sprint Planning kế tiếp.
Bài tập 3 — Chạy thật và đo (nhóm, 1 Sprint). Ở Sprint Planning kế tiếp, chạy Pre-mortem 15 phút theo đúng 5 bước. Ghi lại 2–3 rủi ro top và các action. Đến Retrospective cuối Sprint, mở lại danh sách và đánh giá: rủi ro nào đã xảy ra? Action nào đã giúp? Hiệu quả thực tế thế nào? Chia sẻ kết quả với đội để củng cố thói quen.
Bài tập 4 — Thiết kế biến thể (nâng cao). Đội bạn có gì đặc thù (phân tán, đa văn hóa, nhiều junior, nhiều dependency ngoài)? Hãy điều chỉnh quy trình 15 phút cho phù hợp: thay đổi cách viết note, công cụ, hoặc cách dựng bối cảnh. Ghi lại biến thể của bạn vào toolbox cá nhân (bài 55).
Tóm tắt
Pre-mortem for Sprint là một công cụ quản trị rủi ro nhỏ gọn nhưng cực kỳ giá trị, nhúng thẳng vào Sprint Planning Topic 3, chỉ tốn 15 phút. Cơ chế cốt lõi của nó là prospective hindsight: tua tới tương lai, tuyên bố Sprint đã thất bại, rồi đi ngược tìm nguyên nhân — cách hỏi này giúp đội phát hiện rủi ro cụ thể và sớm hơn nhiều so với câu hỏi "có rủi ro gì không".
Năm bước cần nhớ: Stage (dựng bối cảnh, thì quá khứ, 2 phút) → Generate (viết im lặng, 4 phút) → Share & Cluster (chia sẻ và gom nhóm, 4 phút) → Prioritize (ưu tiên 2–3 rủi ro top, 2 phút) → Mitigate (action có chủ, 3 phút).
Sức mạnh thật sự của công cụ nằm ở hai chỗ: nó biến việc nêu rủi ro từ hành vi tiêu cực thành nhiệm vụ chính thức, phá vỡ groupthink và optimism bias; và nó kéo rủi ro ra ánh sáng sớm hơn vài ngày — khoảng thời gian đủ để cứu một Sprint. Như ba tình huống đã thấy, rủi ro nguy hiểm nhất thường ẩn trong dependency ai cũng "tưởng đã xong", trong story nhỏ nhất, hoặc trong yếu tố con người mà không công cụ kỹ thuật nào bắt được.
Là Scrum Master, hãy nhớ: bạn là người giữ khung thời gian và sự an toàn tâm lý, không phải người phán xét rủi ro. Và đừng quên đóng vòng — đối chiếu dự đoán với thực tế ở Retro để đội tin vào công cụ. Một Pre-mortem làm tốt không khiến đội bi quan; nó khiến đội tự tin hơn, vì họ bước vào Sprint với mắt mở to, biết rõ mình đang đối mặt với gì.