Mở đầu — vì sao bài này quan trọng
Bạn hãy hình dung một đội bóng đá đá xong 90 phút mà không bao giờ vào phòng thay đồ để xem lại trận đấu. Họ cứ ra sân, đá, thua, rồi lại ra sân, đá, lại thua y như cũ — vì chẳng ai dừng lại hỏi: "Tại sao chúng ta thua? Lần sau làm khác đi chỗ nào?". Trong Scrum, Sprint Retrospective chính là khoảnh khắc cả đội vào phòng thay đồ đó.
Đây là sự kiện cuối cùng khép lại một Sprint, và cũng là sự kiện dễ bị xem nhẹ nhất trên thực tế. Nhiều đội nhóm tôi từng làm việc cùng coi Retrospective như một buổi "họp than thở" cho có lệ, hoặc tệ hơn, bỏ luôn vì "tuần này bận quá". Nhưng đứng ở góc độ triết lý Scrum, Retrospective lại là trái tim của vòng cải tiến liên tục. Nếu Sprint Review giúp đội kiểm tra sản phẩm (cái gì được làm ra), thì Sprint Retrospective giúp đội kiểm tra cách làm việc (làm như thế nào) — và đây là điểm khác biệt cốt lõi bạn phải nắm chắc cho kỳ thi PSM I.
Trong bài này, chúng ta sẽ đào sâu đúng một sự kiện duy nhất: Sprint Retrospective. Mục đích thật sự của nó, ai tham gia, timebox bao lâu, kết quả đầu ra là gì, và làm sao để biến nó từ buổi họp nhàm chán thành động cơ cải tiến mạnh mẽ. Đề thi PSM I rất hay "gài" những câu về mục đích và phạm vi của Retrospective, nên hiểu chính xác theo đúng Scrum Guide sẽ giúp bạn ăn điểm chắc chắn.
Khái niệm cốt lõi
Định nghĩa theo Scrum Guide 2020
Theo Scrum Guide, mục đích của Sprint Retrospective là lên kế hoạch cho những cách thức gia tăng chất lượng và hiệu quả (to plan ways to increase quality and effectiveness). Hãy chú ý cụm từ này — nó xuất hiện gần như nguyên văn trong nhiều câu hỏi thi.
Trong buổi này, Scrum Team kiểm tra (inspect) xem Sprint vừa qua đã diễn ra như thế nào, xét trên các phương diện:
- Individuals — con người trong đội đã làm việc, tương tác với nhau ra sao.
- Interactions — sự phối hợp, giao tiếp giữa các thành viên.
- Processes — quy trình làm việc đội đang áp dụng.
- Tools — công cụ đội đang dùng (Jira, GitHub, Slack, CI/CD...).
- Definition of Done — định nghĩa "Hoàn thành" có còn phù hợp không.
Điểm mấu chốt: Retrospective tập trung vào "CÁCH LÀM", không phải "SẢN PHẨM"
Đây là điều bạn phải khắc cốt ghi tâm. Sprint Review nhìn vào Increment — kết quả công việc. Sprint Retrospective nhìn vào quy trình và con người — cách công việc được tạo ra. Một câu hỏi thi kinh điển sẽ mô tả một buổi họp mà đội đang "demo sản phẩm cho stakeholder" rồi hỏi đó là sự kiện gì — câu trả lời là Sprint Review, không phải Retrospective. Ngược lại, nếu đội đang bàn "lần sau chúng ta nên refine backlog sớm hơn" thì đó là Retrospective.
Đầu ra (output) của Retrospective
Scrum Guide nói rõ: Scrum Team xác định những cải tiến hữu ích nhất (most helpful changes) để gia tăng hiệu quả của mình. Những cải tiến cấp thiết nhất có thể được đưa vào Sprint Backlog của Sprint kế tiếp.
Hãy nhớ kỹ hai sắc thái này cho kỳ thi:
- Cải tiến có thể (may) được thêm vào Sprint Backlog tiếp theo — không bắt buộc phải thêm tất cả. Đây không phải mệnh lệnh cứng.
- Scrum Guide 2020 đã bỏ yêu cầu "ít nhất một cải tiến phải đưa vào Sprint Backlog" mà bản 2017 từng có. Vì vậy đáp án "đội bắt buộc phải thêm ít nhất một action item vào Sprint tiếp theo" là SAI theo Guide 2020.
Ai tham gia và timebox
- Người tham gia: Toàn bộ Scrum Team — tức Developers, Product Owner, và Scrum Master. Không có vai trò nào được mời ra ngoài. Stakeholder, sếp, khách hàng không tham dự (trừ khi đội chủ động mời vì lý do đặc biệt, nhưng theo "by the book" thì Retrospective là không gian riêng của Scrum Team).
- Timebox: Tối đa 3 giờ cho một Sprint kéo dài 1 tháng. Sprint ngắn hơn thì buổi này thường ngắn hơn (ví dụ Sprint 2 tuần thường khoảng 1,5 giờ trở xuống).
- Vị trí: Là sự kiện cuối cùng của Sprint, diễn ra sau Sprint Review và trước khi Sprint tiếp theo bắt đầu (tức trước Sprint Planning kế tiếp).
Vai trò của Scrum Master
Scrum Master là một thành viên đầy đủ của Scrum Team, nên cũng tham gia Retrospective với tư cách thành viên. Đồng thời, Scrum Master thường đảm nhiệm vai trò facilitator — người tạo điều kiện để buổi họp diễn ra hiệu quả, an toàn về mặt tâm lý, và đúng mục đích. Lưu ý: Scrum Master facilitate chứ không điều khiển kết luận. Việc rút ra cải tiến gì là của cả đội, không phải Scrum Master áp đặt.
Tình huống thực tế
Tình huống 1 — Tiki và buổi Retrospective "than thở" không lối thoát
Một đội phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn ở Việt Nam (ta gọi tạm là kiểu mô hình Tiki) chạy Sprint 2 tuần. Suốt 4 Sprint liền, mỗi buổi Retrospective đều lặp lại đúng một vấn đề: "API từ team đối tác trả về chậm, làm chúng ta trễ deadline". Mọi người gật gù, ghi vào bảng, rồi... không có gì thay đổi. Sprint sau lại nhắc lại y nguyên.
Diễn giải: Vấn đề ở đây không phải đội thiếu khả năng nhận diện vấn đề — họ nhận ra rất rõ. Vấn đề là Retrospective của họ dừng lại ở bước "kiểm tra" (inspect) mà thiếu hẳn bước "thích nghi" (adapt). Họ liệt kê được nỗi đau nhưng không biến nó thành action cụ thể, có chủ sở hữu, có thời hạn. Scrum Master mới về đã thay đổi cách làm: mỗi Retrospective chỉ chọn một cải tiến quan trọng nhất, gán cho một người chịu trách nhiệm theo dõi, và đưa thẳng vào Sprint Backlog của Sprint kế tiếp như một item thật sự (ví dụ: "Thiết lập cuộc họp đồng bộ 15 phút với team đối tác mỗi đầu Sprint"). Sau 2 Sprint, vấn đề API chậm được giải quyết tận gốc.
Bài học: Retrospective không có giá trị nếu chỉ inspect mà không adapt. Một cải tiến được thực thi tốt hơn mười cải tiến nằm trên giấy.
Tình huống 2 — Startup fintech Singapore và sự thiếu an toàn tâm lý
Một startup fintech ở Singapore có đội 6 Developers, làm việc dưới áp lực rất lớn. Trong Retrospective, mỗi khi có sự cố (ví dụ bug lọt lên production), buổi họp lập tức biến thành phiên "truy tìm thủ phạm": "Ai đã merge cái commit đó?". Kết quả là các thành viên trẻ bắt đầu im lặng, không dám nói thật về khó khăn của mình. Chất lượng buổi Retrospective tụt dốc — chỉ còn vài câu xã giao "Sprint này ổn mà".
Diễn giải: Retrospective chỉ hiệu quả khi có an toàn tâm lý (psychological safety). Đây không phải khái niệm "ngoài lề" — nó gắn trực tiếp với Scrum Value Openness (cởi mở) và Respect (tôn trọng). Scrum Master đã đưa ra một nguyên tắc kinh điển gọi là Prime Directive của Norman Kerth: "Bất kể chúng ta khám phá ra điều gì, chúng ta tin rằng mọi người đã làm tốt nhất có thể trong hoàn cảnh, với kiến thức và nguồn lực họ có lúc đó". Buổi họp được chuyển hướng từ "ai sai" sang "quy trình nào đã cho phép lỗi này xảy ra, và ta sửa quy trình thế nào". Không khí dần cởi mở trở lại.
Bài học: Retrospective là buổi cải tiến hệ thống, không phải buổi đánh giá cá nhân. Khi biến nó thành phiên đổ lỗi, bạn giết chết chính cơ chế cải tiến của đội.
Tình huống 3 — Đội outsource ở Đà Nẵng và Retrospective bị "cắt xén"
Một đội gia công phần mềm tại Đà Nẵng làm cho khách hàng Nhật, Sprint 3 tuần. Vì lịch luôn căng, manager thường yêu cầu "bỏ Retrospective tuần này để kịp release, tuần sau làm bù". Dần dần Retrospective bị bỏ hẳn suốt 2 tháng. Hệ quả: cùng một lỗi triển khai môi trường staging tái diễn 5 lần, mỗi lần mất nửa ngày sửa, và tinh thần đội đi xuống vì "chẳng ai lắng nghe vấn đề của tụi mình".
Diễn giải: Theo Scrum, các sự kiện là bắt buộc (mandatory) và việc bỏ một sự kiện sẽ làm mất đi cơ hội inspect & adapt tương ứng. Bỏ Retrospective đồng nghĩa đội tự tước đi cơ chế tự sửa chữa duy nhất dành cho quy trình. "Để dành làm bù sau" là một ngộ nhận — cải tiến mất giá trị nếu không diễn ra kịp thời trong nhịp Sprint. Khi Scrum Master giải thích với manager rằng nửa ngày x 5 lần lỗi (2,5 ngày công lãng phí) lớn hơn nhiều so với 1,5 giờ Retrospective, manager mới đồng ý khôi phục sự kiện này.
Bài học: Retrospective không phải chi phí, nó là khoản đầu tư. Bỏ nó để "tiết kiệm thời gian" là cách tốn thời gian nhất.
Hướng dẫn từng bước
Dưới đây là một khung tổ chức Retrospective hiệu quả, bạn có thể áp dụng ngay. Lưu ý đây là kỹ thuật thực hành — Scrum Guide không quy định cấu trúc cụ thể, nên trong bài thi đừng coi các bước này là "luật".
- Thiết lập không khí (Set the stage). Mở đầu bằng việc nhắc lại mục đích buổi họp và Prime Directive. Tạo cảm giác an toàn, mọi ý kiến đều được tôn trọng. Một câu hỏi khởi động nhẹ nhàng giúp mọi người "mở miệng".
- Thu thập dữ liệu (Gather data). Cùng nhìn lại Sprint vừa qua một cách khách quan: timeline sự kiện, các số liệu (số bug, số việc hoàn thành/dở dang), cảm xúc của đội. Mục tiêu là tạo bức tranh chung trước khi phán xét.
- Tạo insight (Generate insights). Đào sâu tại sao mọi việc diễn ra như vậy. Kỹ thuật "5 Whys" (hỏi "tại sao" 5 lần liên tiếp) rất hữu ích để đi từ triệu chứng đến gốc rễ. Ví dụ: "Bug lọt lên production → vì chưa test → vì thiếu thời gian → vì ước lượng sai → vì không refine kỹ".
- Quyết định hành động (Decide what to do). Cùng đội chọn ra 1–3 cải tiến quan trọng nhất. Mỗi cải tiến phải cụ thể, đo lường được, có người chịu trách nhiệm. Đừng tham lam chọn 10 việc — đội sẽ không làm nổi.
- Đóng buổi họp (Close). Tóm tắt action items, chốt ai làm gì, và nhanh chóng "retro về buổi retro" (buổi này có hiệu quả không?).
- Đưa cải tiến vào Sprint Backlog kế tiếp. Những cải tiến cấp thiết nên được đưa vào Sprint Backlog của Sprint sau như công việc thật, để chúng được theo dõi và hoàn thành chứ không bị lãng quên.
- Theo dõi (Follow-up). Ở Retrospective tiếp theo, mở đầu bằng việc kiểm tra: action item lần trước đã làm xong chưa, có hiệu quả không. Đây là vòng lặp khép kín giúp cải tiến thực sự bám rễ.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Retrospective với Sprint Review. Đây là cái bẫy số một trong đề PSM I. Hãy nhớ: Review = kiểm tra Increment/sản phẩm (có stakeholder); Retrospective = kiểm tra quy trình/con người (chỉ Scrum Team). Khi đọc câu hỏi, hãy soi ngay vào đối tượng đang được "inspect".
Lỗi 2 — Tưởng phải bắt buộc thêm cải tiến vào Sprint Backlog. Theo Guide 2020, cải tiến có thể (may) được thêm — không bắt buộc. Đề thi rất hay gài chữ "must" để lừa bạn.
Lỗi 3 — Biến Retrospective thành phiên đổ lỗi. Vi phạm cả Openness lẫn Respect, và phá hủy an toàn tâm lý. Tập trung vào hệ thống, không vào cá nhân.
Lỗi 4 — Bỏ Retrospective khi "bận". Sự kiện là bắt buộc. Bỏ nó là tự cắt đi cơ chế cải tiến.
Lỗi 5 — Chỉ inspect mà không adapt. Liệt kê vấn đề mãi mà không hành động. Retrospective không có action item thực thi được thì vô nghĩa.
Mẹo ghi nhớ cho thi:
- Mục đích = plan ways to increase quality and effectiveness.
- Timebox = tối đa 3 giờ cho Sprint 1 tháng.
- Người tham gia = cả Scrum Team, không có stakeholder.
- Vị trí = sự kiện cuối cùng, kết thúc Sprint, sau Review.
- Đầu ra = cải tiến có thể đưa vào Sprint Backlog kế tiếp.
Bài tập thực hành
- Phân biệt sự kiện. Với mỗi tình huống sau, xác định đó là Sprint Review hay Sprint Retrospective: (a) Đội demo phiên bản mới của app cho khách hàng và nhận phản hồi; (b) Đội bàn về việc giao tiếp giữa Dev và PO chưa tốt và cách cải thiện; (c) Đội quyết định đổi từ Jira sang công cụ khác vì tool hiện tại gây phiền. (Gợi ý đáp án: a = Review; b và c = Retrospective.)
- Tự kiểm tra trí nhớ. Không nhìn lại bài, hãy viết ra: mục đích Retrospective, timebox tối đa cho Sprint 1 tháng, ai tham gia, sự kiện này diễn ra trước/sau Sprint Review, và đầu ra là gì.
- Tình huống phản biện. Một Scrum Master nói: "Cuối Retrospective, tôi luôn ép đội phải chốt đúng 3 action item và bắt buộc đưa cả 3 vào Sprint Backlog tiếp theo, nếu không thì không cho kết thúc họp". Theo Scrum Guide 2020, cách làm này đúng hay sai ở điểm nào? (Gợi ý: sai ở chỗ "bắt buộc" — Guide 2020 nói cải tiến có thể được thêm; và Scrum Master không nên áp đặt số lượng cố định.)
- Áp dụng thực tế. Nhớ lại lần gần nhất bạn làm việc nhóm (dự án, môn học, công việc). Hãy tổ chức một "mini-retrospective" theo khung Start-Stop-Continue: việc gì nên bắt đầu làm, việc gì nên ngừng, việc gì nên tiếp tục. Chọn ra một cải tiến và cam kết thực hiện ở lần sau.
Tóm tắt
Sprint Retrospective là sự kiện khép lại Sprint với một mục đích duy nhất nhưng vô cùng quan trọng: lên kế hoạch để gia tăng chất lượng và hiệu quả của Scrum Team. Khác với Sprint Review nhìn vào sản phẩm, Retrospective nhìn vào cách đội làm việc — con người, tương tác, quy trình, công cụ và cả Definition of Done.
Hãy ghi nhớ các con số và ranh giới cốt lõi: toàn bộ Scrum Team tham gia (không có stakeholder), timebox tối đa 3 giờ cho Sprint một tháng, diễn ra sau Sprint Review và trước Sprint Planning kế tiếp. Đầu ra là những cải tiến hữu ích nhất, có thể — chứ không bắt buộc — được đưa vào Sprint Backlog của Sprint tiếp theo.
Trên thực tế, một Retrospective tốt cần ba điều: an toàn tâm lý để mọi người nói thật, kỷ luật để inspect đi cùng với adapt, và sự kiên định để không bỏ buổi họp khi áp lực dâng cao. Đây chính là động cơ giúp một đội Scrum không ngừng tốt lên qua từng Sprint — và là kiến thức bạn cần nắm chắc để vượt qua những câu hỏi "gài bẫy" trong kỳ thi PSM I.